Home/ Questions/Q 51471
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T16:45:20+00:00

I have a custom class loader so that a desktop application can dynamically start

  • 0

I have a custom class loader so that a desktop application can dynamically start loading classes from an AppServer I need to talk to. We did this since the amount of jars that are required to do this are ridiculous (if we wanted to ship them). We also have version problems if we don’t load the classes dynamically at run time from the AppServer library.

Now, I just hit a problem where I need to talk to two different AppServers and found that depending on whose classes I load first I might break badly… Is there any way to force the unloading of the class without actually killing the JVM?

Hope this makes sense

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The only way that a Class can be unloaded is if the Classloader used is garbage collected. This means, references to every single class and to the classloader itself need to go the way of the dodo.

    One possible solution to your problem is to have a Classloader for every jar file, and a Classloader for each of the AppServers that delegates the actual loading of classes to specific Jar classloaders. That way, you can point to different versions of the jar file for every App server.

    This is not trivial, though. The OSGi platform strives to do just this, as each bundle has a different classloader and dependencies are resolved by the platform. Maybe a good solution would be to take a look at it.

    If you don’t want to use OSGI, one possible implementation could be to use one instance of JarClassloader class for every JAR file.

    And create a new, MultiClassloader class that extends Classloader. This class internally would have an array (or List) of JarClassloaders, and in the defineClass() method would iterate through all the internal classloaders until a definition can be found, or a NoClassDefFoundException is thrown. A couple of accessor methods can be provided to add new JarClassloaders to the class. There is several possible implementations on the net for a MultiClassLoader, so you might not even need to write your own.

    If you instanciate a MultiClassloader for every connection to the server, in principle it is possible that every server uses a different version of the same class.

    I’ve used the MultiClassloader idea in a project, where classes that contained user-defined scripts had to be loaded and unloaded from memory and it worked quite well.

    • 0