• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Devaka Cooray
  • Ron McLeod
  • paul wheaton
Saloon Keepers:
  • Tim Moores
  • Piet Souris
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Frits Walraven
  • Scott Selikoff

Unloading classes at runtime

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

If I were to design a hot deploy/undeployer plugin system in my application, I would need to write my own ClassLoader to load in any arbitrary user jar at runtime right? What I haven't figured out yet is how can I unload these classes if I were to remove the plugin at runtime as well? I didn't see a unloadClass method in ClassLoader. Any idea how I would approach this? Is there a library that does this already?

Thanks,
-Z
 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Classes can be unloaded when, and only when, the classloader than loaded them is garbage-collected. When you need to discard the classes, ditch the class loader, make sure nothing is referencing any objects of those types, and then the system will take care of the rest.
 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:
Classes can be unloaded when, and only when, the classloader than loaded them is garbage-collected. When you need to discard the classes, ditch the class loader, make sure nothing is referencing any objects of those types, and then the system will take care of the rest.



But this wont be a guaranteed operation would it, relying on the garbage collector?
 
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh:
But this wont be a guaranteed operation would it, relying on the garbage collector?



With the modern Garbage collectors, you can mostly assume that it is guaranteed i.e. unused instances(in this case the classloader and the loaded classes) will be GCed.

But, let us assume it does not. Then what is the negative that we are getting. In my opinion the only negative is:

The loaded classes use memory.

So, the guarantee is that before JVM throws an Out of Memory, any unused memory will be GCed. If this guarantee is maintained then there is no use what so ever to think about unloading classes.
[ September 17, 2008: Message edited by: Nitesh Kant ]
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nitesh Kant:

With the modern Garbage collectors, you can mostly assume that it is guaranteed i.e. unused instances(in this case the classloader and the loaded classes) will be GCed.



Yes. But what I meant was you cant rely on when they will be GC'd.

Imagine a scenario where you got an application running. Now you want to upgrade the plugin. So you ditch the current class loader. The you replace the jar and invoke the class loader again thinking it will load the modified plugins.

If the old class loader has not been GC'd I dont see how the new plugins will be loaded.

This is what I mean when I said it wont be a guaranteed operation as you do not have control over when the objects are GC'd.
 
Ranch Hand
Posts: 378
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,
What do you mean here by "ditch the classloader" ?
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gamini Sirisena:
Hi All,
What do you mean here by "ditch the classloader" ?



Dereference the object so it is eligible for GC
 
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How about a custom ClassLoader, which reads the new jar and invokes defineClass() again with the new byte code? Check out the following custom ClassLoader from the GATE NLP framework:
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh:
Imagine a scenario where you got an application running. Now you want to upgrade the plugin. So you ditch the current class loader. The you replace the jar and invoke the class loader again thinking it will load the modified plugins.



Oops, i dont think this is something one should do when facilitating "hot deployment"
Hot deployment means that one can deploy a new plugin without bringing down the entire application.
If you are re-deploying a plugin, you must instantiate a new classloader and discard the old one.
Re-using the same classloader sounds a little dicey.

Guido: How about a custom ClassLoader, which reads the new jar and invokes defineClass() again with the new byte code?



You mean for every class that it is trying to load after change in jar files?
If yes, then how is it different from discarding the old loader and instantiating a new one?
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nitesh Kant:

Hot deployment means that one can deploy a new plugin without bringing down the entire application.



Yes of course. When did I say bring down the whole application?
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Im not sure I can follow all this argument but:

1. Nothing - class object or instances - will be GCed if there are still references to it.
2. If there are no references to the class object, it can not be reached, therefore there is no potential conflict.
3. For dynamic plug-ins you will be working indirectly with Java reflection, interfaces, abstract classes,etc. - NOT directly with the classes. Therefore you probably are worrying about something that cant happen.

After you dig into classloaders and dynamic plugin object creation you will find a whole different set of problems. I certainly did


Bill
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh:
Yes of course. When did I say bring down the whole application?



Ouch, i did not mean that you said so but i was just defining the hot deployment thing
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE MySQL Database Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

William:
3. For dynamic plug-ins you will be working indirectly with Java reflection, interfaces, abstract classes,etc. - NOT directly with the classes. Therefore you probably are worrying about something that cant happen.


I did not get this. Actually, the discussion was to reload/hot-deploy new plugin classes. Whether it is through reflection or not, the classes will be loaded in the JVM and we need to worry about throwing away old class definition and loading new ones.
Probably I did not understand what you were saying.

William:
After you dig into classloaders and dynamic plugin object creation you will find a whole different set of problems. I certainly did



Absolutely, there is a lot to plugins than it looks from outside.
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Nitesh Kant:

Ouch, i did not mean that you said so but i was just defining the hot deployment thing



My bad.
The class loader concept is not really crystal clear (at least to me), with all the nuances, which probably caused the confusion on my part.

My understanding is as follows:
You got the app running. You use some class loader to load some specific plugin classes.
When you want to hot deploy, (without bringing down the app of course) you do something like:


As per my understanding of the subject, this should effectively dereference the previous "loader" and make it eligible for GC.
Will this ALSO unload the classes previously loaded by "loader"?

It is quiet possible that I have managed to go off on a tangent, and someone will point me to the basic java tutorial !

 
Rancher
Posts: 43028
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As per my understanding of the subject, this should effectively dereference the previous "loader" and make it eligible for GC.


It should, provided that there are no other reachable references to the classloader. That means that all objects instantiated from classes loaded through that classloader must not be reachable either (and thus be eligible for GC).
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Got it.
Thanks.
 
Always! Wait. Never. Shut up. Look at this tiny ad.
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic