|Wednesday, March 6, 2002|
One of the best electric guitarists around was Eddie Maggot Brain Hazel. Eddie played with the P-Funk crew, amongst many others. A particularly good tribute track named Blasters featuring Eddie Hazel appears on a Bootsy's New Rubber Band album titled Blasters of the Universe.
10:04:26 PM pontificate
If you are ever in NYC, grab a slice of the Bayou Beast from Two Boots Pizza (Grand Central, Village, other spots). Crawfish, shrimp, andouille sausage, jalapeno peppers...
9:17:24 PM pontificate
Jim Roepcke asks Can someone please explain this [the Java Extensions Mechanism] to me in a sentence or two of english (even geek english) instead of Sunglish?
He found the answer through a Tutorial on the JavaSoft site.
However, there is a caveat that most people don't fully realize. I sure didn't and when it bit me, I spent quite a bit of time very confused, very frustrated, and generally not enjoying my development experience.
Namely, a particular section of the tutorial has this to say:
What isn't explicitly said, and should be, is that a class found via the class loader for the extensions cannot find classes that are only available via the CLASSPATH when using the rather common forName(String className) method as that method invokes forName(String name, boolean initialize, ClassLoader loader) where the loader is specified by a call to ClassLoader.getCallerClassLoader(). If the caller's class loader is the extension class loader, its parent is the bootstrap class loader and, as such, if the class is in the CLASSPATH, it will not be found.
Example: In log4j, it is common to specify various classes in the configuration file that are used as the destination for log messages, to implement new logging categories, or for other purposes. If log4j.jar is installed in the extensions directory-- very common-- and the configuration file specifies a class that can only be found via something mentioned in the CLASSPATH, the application will fail with a very odd looking class not found exception.
To further complicate matters, the behavior at compile time is subtly different because the ordering doesn't matter; if a class normally found via the extensions class loader references a class normally found in the CLASSPATH, nothing nasty happens but the app will still fail at runtime.
Of course, this all means that you can have a working app on one machine that is referencing everything via the CLASSPATH where the same app fails on another machine with the same set of jar files, but some are in the extensions directory.
There is also the interesting possible situation where the extensions and the classpath class loader both know about different versions of a particular class and the above situation could lead to one version of the class being used in one situation and the other in other situations.