I was recently asked in an interview about the order in which classloaders are called when a class is loaded.
Unfortunately I've never had the need to write my own classloader so at the time was unfamiliar with the intricacies of classloading.
This got me wondering, what reasons are their to write your own classloader.
So that's my question: What scenarios have people faced which required the need to writing their own classloaders?
I'm currently working on an extremely large application that is highly modularized, i.e. it consists of literally hundreds of JAR files. This meant that the classpath string became huge, causing all sorts of problems in all sorts of places, because of various development tools's inability to deal with a 5KB classpath string. This was solved by writing a custom classloader that reads its classpath from a file.
Typical reason is that your application is hosting other applications which are using same libraries in different versions in the same runtime (e.g. Tomcat). So you have to make sure that your classloader can provide different versions of the same class for each of these applications.
EDIT:
To clarify this a little bit (see confusion in comments): When said "your classloader" I ment "an implementation of java.lang.ClassLoader" not an instance of such a class. Actually it's your classloaders in both meanings: the Tomcat people implemented different ClassLoader-classes and have even more instances at runtime...for details see the corresponding docs.
Boredom and the desire to torment my co-workers when they had to maintain my code. :)
Some places actually store classes in a database (well there used to be places, not sure if there are anymore) and use a class loader to get the classes from the database at run time.
I had to implement a ClassLoader once when I wanted to load up classes in .jar files from within a .jar file (this was a few years ago, I'm sure there are tools now which can do that for you). i.e., you would put your dependency .jar files into one .jar file.
But that's the only time, in my experience writing a custom ClassLoader is a pretty rare thing.
You can do software releases without the downtime, kinda of situations in 24x7 running systems.
You can write your own class loader call that from JMX and replace the class file at run time.
I have seen a good post here. It talks about different class loaders, class loader hierarchy and custom class loader.
We had an application framework that had applications based on it which were 'statically tied'. This meant that you needed to have a jvm instance per application you wanted to run, which was not only bad for memory use, but meant that you could not have a super application from which to launch the various apps, or any easy (non-interprocess) communication between the running apps.
Since the whole thing was run from webstart (i.e with a bunch of jars as the classpath), the solution to preventing the system classloader from finding the classes was to offset the packages. For expample if you had a class a.b.X in an application foo then it would be in the jar file as foo/a/b/X.class.
At my last job we implemented a server that could have "plug-in logical query definitions". (The client could call queries by name, the server looked up the registered query for that name and ran it).
The query definitions were code and/or metadata contained in a jar.
The jar was uploaded to the server though our console application.
When uploaded (and later when the server restarted), our framework would create a class loader for the jar to load it into the running server.
I have do that one time. We have to use a API provide by a third party vendor, and this API use a strange version of hibernate3.jar. So, we had to load this specific jar with a custom classloader in order to avoir "serial version UID" exception.
