• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Default classloaders and custom classloaders

 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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: "





"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!

 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic