Default classloaders and custom classloaders

[Padma Priya]

Hi all,

I am new to the concept of class loaders.

I have read several online resources on this, but still I am a bit confused on the below points.

1) Using custom classloaders can we control the default behaviour(bootstrap, Extension and system).
2) By control I mean can we completely override the default behaviour and only call my custom class loader.
3) or Can I have the default behaviour along with the custom behaviour.
4) How can I use custom classloaders to reinforce Singletoness.

Thank you in advance for your time.

[Tim Holloway]

Java actually uses chains of classloaders. This is very apparent in products such as web application servers (such as WebSphere and Tomcat), where each web application has its own unique classpath, as do various components within the server.

I don't think you'd really want to override the basic chain and do all the classloading yourself. You'd probably run into issues when you couldn't load java.lang.Object, for example.

It's also not a good idea to attempt a classloader to enforce the Singleton design pattern. Classloaders work with classes., Singleton is a type of class instance.

What custom classloaders are good for is to enhance the basic class-loading framework. As an example, webapp WARs add classloading to all files found under the WAR's WEB-INF/classes directory and inside JARs under WEB-INF/lib. Normal classloading cannot look at jars within other JARs, and classes can appear anywhere within a JAR, subject to package-name/directory synthesis rules.

[Padma Priya]

Thank you very much for the reply.

I came accross this http://snehaprashant.blogspot.co.uk/2009/01/singleton-pattern-in-java.html which says

"If you want to make sure the same classloader loads your singletons, you must specify the
classloader yourself; for example: "

private static Class getClass(String classname) throws ClassNotFoundException {
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
    if(classLoader == null) 
        classLoader = Singleton.class.getClassLoader();
      return (classLoader.loadClass(classname));
}

"The preceding method tries to associate the classloader with the current thread; if that classloader is null, the method uses the same classloader that loaded a singleton base class. The preceding method can be used instead of Class.forName(). "


But I am not able to understand it. What if the class loader with the current thread is different from the classloader that loaded the singleton base class. How is it possible that the current thread will always return the same classloader that loaded a singleton class.

Can somebody explain.

Thank you!

[Paul Clapham]

I think there's several things wrong with that. The major thing wrong with it is that it's obsessing over the Singleton pattern, a pattern which is greatly overrated and widely abused.

And when you said "What if the class loader with the current thread is different from the classloader that loaded the singleton base class" you were right, as well as "What if the context class loader of the current thread is different than the context class loader of a different thread which was also used to load that singleton?"

So yeah, I think that's not very useful code. Especially since it seems to require a hardcoded "Singleton" class whose only purpose is to be loaded by the system class loader (which (I think) is what's going to happen there (but I could be wrong)).

A more practical way to approach singletons is to discard all of the information in that blog post because it's only of historical interest. Just create an enum with a single element and you've got a bulletproof singleton, without any of the fancy footwork you used to need.

[Paul Clapham]

Paul Clapham wrote:I think there's several things wrong with that.

Including the fact that the code you posted returns a Class object, which doesn't provide any way to get a singleton object of that class. Given the Class you can't create an instance via reflection, since its constructor should be private if it's supposed to be a singleton. And if an instance already exists, there's no way to get a reference to it.

[Tim Holloway]

Something to consider.

Supposed you have 2 webapps. Both use a library that contains a singleton class. Actually, I've got webapps with lots of singleton classes, and not all of them are library classes, but I'm simplifying.

Now the question is: Just how "single" should this class be? In many cases, you have a single class instance - for example, a database connection manager. But the database connection manager for webapp A is connected to an Oracle database and the database connection manager for webapp B is connected to a MySQL database. Within each app, there's just the one instance, but they're 2 different actual instances because the 2 webapps have 2 different class contexts. The same classloader classes may have set up these contexts, but they're still completely separate from each other.

Now let's move up the tree. Each webapp has a classpath that's a branch of the overall web server classpath tree. Classes like javax.servlet.HttpServlet, however, are shared (note I said classes and not instances here. So those classes come from the trunk of the classpath tree. You could also put a Singleton class in that trunk and then it would truly be single for all webapps. Note I'm speaking theoretically here. Good practice says that singleton or not, you shouldn't be putting application classes into the trunk classpath segments of webapp servers.