What reasons have people had to write their own classloader

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?

From stackoverflow

• 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 classloader**s** in both meanings: the Tomcat people implemented different ClassLoader-classes and have even more instances at runtime...for details see the corresponding docs.

  pgras : actually you would have to load different versions of the same class with different instances of your classloader. One classloader cannot have two versions of the same class at the same time...

  Mr. Shiny and New : @pgras: I think that's what kai1968 meant... "your classloader" == "the classloaders used in your application", at least that's how I read it.

• 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.

• Have a look at this question.

• 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.

  Brian Deterling : My company did this so that a developer could write a plugin and upload it into the application with no downtime. We mostly switched to using scripting languages (Groovy, JRuby) for that functionality, but it was fun while it lasted.

• 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.

• 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.

• Boredom and the desire to torment my co-workers when they had to maintain my code. :)

• 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 came across an article which talks about why (very briefly) OSGI uses a custom Classloader.

• 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.

• In the beginning, there was just me and the snow, and silence...

  Then appeared the bear, and silence died: I wasn't alone anymore. I saw my life vanished in a breath, and then realized I had to do something, or die by the bear right now.

  Afraid and confused, i wrote a classloader

  Every properly written classloader can save your life. As i was properly writing my own classloader, the bear just sat next to me, looked at my code, optimized out a nasty loop and went away.

  (writing classloaders is also the quickest and easiest way to look like a serious guy when you are writing java code

  Wallacoloo : Matching each start parenthesis with an end one is also an easy "way to look like a serious guy when you are writing java code" ;-)