Forum Stats

  • 3,817,367 Users
  • 2,259,322 Discussions
  • 7,893,760 Comments

Discussions

Base ClassLoader No Longer from URLClassLoader

3388296
3388296 Member Posts: 2
edited Feb 7, 2018 9:56PM in Java SE Early Access

Since 1.1, the way to programmatically add JAR files to a class path was to get the default ClassLoader and cast it to URLClassLoader to invoke the AddURL method.  This is now broken in OpenJDK 9.  Here is the info:

openjdk-9-jre-headless.

openjdk version "9-Ubuntu"

OpenJDK Runtime Environment (build 9-Ubuntu+0-9b134-2ubuntu1) OpenJDK Server VM (build 9-Ubuntu+0-9b134-2ubuntu1, mixed mode)

Exception in thread "main" java.lang.RuntimeException: java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: java.base)

...

Caused by: java.lang.ClassCastException: jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) cannot be cast to java.net.URLClassLoader (in module: java.base)

        ... 2 more

And here is the code (yes, it is in a try/catch and newpath is already sanity checked):

            final URLClassLoader urlClassLoader = (URLClassLoader) MyClass.class.getClassLoader();

            final Method addURL = URLClassLoader.class.getDeclaredMethod("addURL", URL.class);

            addURL.setAccessible(true);

            addURL.invoke(urlClassLoader, new File(newpath.trim()).toURI().toURL());

Best Answer

  • 3388296
    3388296 Member Posts: 2
    edited Feb 3, 2017 12:34AM Answer ✓

    This is due to the Java 9 architecture precluding use of URLClassLoader as a superclass for the system ClassLoaders.

    I implemented the following changes with noted caveats:

    Add the ClassPath property to the jar Manifest file to provide startup classpath additions.

    When an extended classpath is required, I use:

    Class.forName("nameofclass", true, new URLClassLoader(urlarrayofextrajarsordirs));

    The above line also attaches the extended classpath to nameofclass so any other class definitions in nameofclass will also resolve.

    Caveats:

    java.util.ServiceLoader uses the thread's ClassLoader context Thread.currentThread().setContextClassLoader(specialloader);

    java.sql.DriverManager does honors the calling class' ClassLoader, -not- the Thread's ClassLoader.  Create Driver directly using Class.forName("drivername", true, new URLClassLoader(urlarrayofextrajarsordirs).newInstance();

    javax.activation uses the thread's ClassLoader context (important for javax.mail).

    Hopefully this will help the thousands of other authors who have relied on the application ClassLoader being a subclass of URLClassLoader.

    Further elaboration on java.sql.DriverManager issue.  While Class.forName(..., true, classloader) properly loads the class for the JDBC driver and registers it with DriverManager, it is unusable via DriverManager because DriverManager tries Class.forName(jdbcdrivername, true, caller.getClassLoader()) which fails since class caching is done at the child ClassLoader level, not the parent level.

Answers