Class.forName() is evil…. We’ve all

Class.forName() is evil….

We’ve all done it before I guess. Called Class.forName( “” ) to load some class at runtime based on some configurable class name. At first it seems very groovy.

However this does not work very well in application servers, containers or various environments like Maven, Ant, JUnit etc. The days of everything being in the system class loader are over, now we need to live in a multiple-classloader world.

Solution? Try use the current thread’s context class loader or the class loader used to load your code. So try replace this…

Class theClass = Class.forName( className );

with this more verbose version (which could easily be wrapped in a helper method)

Class theClass = null;
try {
    theClass = Thread.currentThread().getContextClassLoader().loadClass( className );
catch (ClassNotFoundException e) {
    theClass = getClass().getClassLoader().loadClass( className );

Henri, this could be a possible addition to commons lang?

While we’re talking about living in multi-classloader worlds, bob’s new project ClassWorlds looks very groovy.

[James Strachan’s Radio Weblog]

This certainly goes a long way towards solving classloader issues – I always seem to get bitten by XML parsers in this regard. What it doesn’t always solve is the situation of colliding packages. I’ve hit a situation where the app. server is using a version of Xerces thats older than the version my app. wants to use. This gets messy, and the exact behaviour depends on your app. server’s classloading policy (it doesn’t help that the servlet spec. appears to be in conflict with the java language spec. on the issue of classloader delegation order).


Just been playing with the

Just been playing with the EOB-Prevayler demo. Very cool. The app that wouldn’t die. Bounce the client: state is preserved. Bounce the server: state is preserved. Database Not Included (or required). Even cooler: open 3 or 4 windows and watch them all update when one is changed. Very, very cool.

Transparent RMI. There’s an interesting

Transparent RMI. There’s an interesting article over on JavaWorld: “Empower RMI with TRMI“. Transparent RMI makes it simpler to create RMI services. No more extending Remote and having every method throw RemoteException & it also centralizes error handling on the client side. It appears to be using dynamic proxies to simplify things… I need to investigate this further. [Otiose Cognitions]

While you’re at it, have a look at altRMI.

Applet security redux. I

Applet security redux.

I have finally come upon a solution that is less expensive than paying

the $200 plus $100/year to Thwaite for a digital certificate. I just put the following into my Java Plugin JRE’s file:

   grant codeBase "" {

Now, this is fine for me because I trust myself. But, for example, what

if Anthony Eden was to ask

his users to do this, substituting for in the above snippet? Anthony would be asking his

users to trust in the following things:

  • Neither Howard Kistler, Dave Johnson, nor Anthony Eden have put no malicious code in Ekit

  • An evil hacker will not break in to Anthony’s site and replace

    ekitapplet.jar with malicious code

Is that too much to ask of Anthony’s Roller users? If it is, then we

need to buy a certificate for Ekit and hope that this one certificate

would be good for all Roller users.

BTW, this is my first Ekit post using Mozilla.

[Blogging Roller]

Presumably, even with a certificate, users would still have to trust that none of the authors had put any malicious code into it? All the certificate does is assert where it came from. You are still required to trust the source.

BCELify BCEL. A tool


BCEL. A tool to build classes on the fly and output them as bytecode. Complex stuff. Luckily it comes with BCELifier. This tool can take an existing .class file and generate the BCEL java source code to build that class. Very cool.

What this means is that if (like me) you find BCEL itself a mite tricky, you can write your class in the normal way, compile it, BCELify it and end up with the source code you need to feed BCEL with to get the same result. Groovy. This reminds me of my dim past, recording VBA macros in Excel to find out how to do something, then hacking the generated code into what I wanted. [Pushing the envelope]

I’m really not sure how I feel about this. We are really re-treading the boards that lisp trod with it’s macro system many moons ago. I suppose the complexity of our solutions is the result of refusing to swallow the lisp/scheme mantra of code and data being one.[Brett Morgan’s Insanity Weblog Zilla]

Indeed. I’m still looking for the ‘perfect’ language. Java with closures, multiple inheritance, dynamic execution (like Perl’s ‘eval’) and primitives as first-class objects (a la Smalltalk) would be pretty cool.

This article on an imaginary ‘Java 3’ also makes for an interesting read.