Prepend
2006-01-31
  Custom Java ClassLoaders- Don't Do It!
I've been working with Java for about 8 years or so and about once per year I come across someone who tries to write a custom ClassLoader. Here's my rule: If you aren't an app server, don't write a new ClassLoader implementation.

Normally the attempt is made for a very good reason, there's no "hot reloading" of Class definitions in Java by default. It sounds really easy to add some checks to a ClassLoader to see if a .class file's time stamp has changed or to add a flush system. I would love for this to exist. I would use it in a heart beat. Jakarta, BEA, JBoss, IBM and Oracle should add this functionality. But there's a reason why there is no project in Jakarta commons: ClassLoader hierarchies can be very complex.

Here's a recent scenario. I use OAS and WebSphere a lot to deploy and test my apps. I use JAAS for authentication. This normally works fine because OAS and WAS allow for you to change the ClassLoader hierarchy to check the current loader before the parent. So when I use JAAS within my ear, the LoginModule classes can be stored in the ear, instead of at the app server or system ClassLoader level. This is different than the default behavior that Sun suggest, but is highly useful. As without this function, I couldn't use JAAS to authenticate (I can't put my classes in the app or system classpath for reasons I'll explain some other day).

I'm using an embedded service engine, that I won't name but is pretty cool, and it builds it's own Threads and ClassLoaders. But it does it like Sun says you should, not how OAS and WAS do it. So this means that when I try to use classes that live in the app or system classpath (like OAS' and WAS' JAAS frameworks- implicitly called by LoginContext.login), I get a bunch of NoClasDefFoundErrors. And there's really no work around than to drop my entire class library in the app or system classpath, which I can't do. So this app that I have to embed and use is sucking a bit because it can't call out classes stored in the very ear that is running the app. The effort was good-hearted, but it caused me extra work to hack around it.

So my plea is this: Don't mess with ClassLoaders, you can't do it. If you are a genius and make the perfect ClassLoader, start a project in commons so the world can benefit and I don't have to muck around in near-genius code that doesn't quite make it.
 
Comments:
I can definitly think of cases where you want to write a custom class loader. As an example in cases where the class files themselves are located elsewhere than the filesystem. (Network, Database etc).

However, I totally agree with you. Classloaders should follow the normal rules, and don't sureprise us poor developers with noclassdef's etc .-)
 
Genius developers never ever create Jakarta Commons projects. All Jakarta Commons projects suck ;-)
 
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/flow/javascript/fom/CompilingClassLoader.html
 
Post a Comment



<< Home
Technical and personal notes from Brian Lee, technologist/enterprise architect/software developer/soa guy.

ARCHIVES
February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / May 2007 / June 2007 / August 2007 / September 2007 / October 2007 / April 2008 / July 2008 / January 2009 / May 2009 / June 2009 /
My Photo
Name: Brian Lee
Location: Atlanta, Georgia, United States

 
Web prepend.com






Powered by Blogger