1

I am looking for a way to replace a jar with old functionality with a new one without stopping the whole application. I have googled for this a little bit (Unloading classes in java?, Dynamically loadable and unloadable application modules in Java - how?), and have found 3 possible solutions:

  1. OSGI, which looks too complicated for my purposes: class unloading is the only thing I need from this powerful specification.
  2. Own implementation, which implies creating own Classloader, loading jars with its help, and when time comes to dismiss the jar - expose Classloader instance to GC and hope that GC will remove it together with all loaded jars, which may not happen immediately.
  3. Copy the stuff application servers do :) That is the purpose of my question.

Is there any explanation on how Tomcat unloads the classes (wars)? Is it possible to reuse this in my application?

PS Just while I was writing this post 2 strange ideas came into my head:

  1. may be we can start another instance of application with new set of jars and switch input and output data flows from old one to new one. If there is a place to preserve state - it can be more quick than full restart.
  2. may be Spring may help? It can dynamically register beans, but this looks like somewhat ugly solution, and it cannot unload them anyway; may be, Spring Boot may help?
Community
  • 1
  • 1
MiamiBeach
  • 3,261
  • 6
  • 28
  • 54
  • 1
    OSGi may appear complicated because it has to handle a lot of corner cases. If you go route 2 or 3, you are likely to end up reimplementing a significant portion of OSGi -- except without the benefit of our 18 years experience doing this :-) – Neil Bartlett Oct 18 '16 at 23:33

3 Answers3

2

A class can be unloaded only when it and its class loader are unreachable and thus eligible for garbage collection. Since the class loader can reach every class it loaded and every class loaded by a class loader can reach its class loader and every object which is an instance of a class can reach its class, this means that the class loader, all the classes it loaded and all the objects which are an instance of those classes must all be unreachable and eligible to be garbage collected. Only then, can a class be "unloaded" when that complete object graph is garbage collected.

BJ Hargrave
  • 9,324
  • 1
  • 19
  • 27
1

I can only partially answer you questions, however better than nothing... You are right, modularity is a quite a tedious topic (at least until there's Java 9).

Ad idea 2 (Spring): I already spent some thoughts on Spring Boot over here and came to the conclusion that I'll stick either to OSGI (it's worth getting into it) or to a pure Microservice architecture.

Community
  • 1
  • 1
gtonic
  • 2,295
  • 1
  • 24
  • 32
1
Zildyan
  • 1,261
  • 9
  • 11
  • Thanks, Zildyan! As far as I understand this relates to hotswapping techniques. But I am interested more in loading/unloading techniques. The difference is that hotswapping replaces some class instance in memory, while I want to add it and remove it completely. – MiamiBeach Oct 20 '16 at 15:19