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

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

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: The extension framework makes use of the new class-loading mechanism in the JavaTM 1.2 platform. When the runtime environment needs to load a new class for an application, it looks for the class in the following locations, in order: Bootstrap classes: the runtime classes in rt.jar and internationalization classes in i18n.jar. Installed extensions: classes in JAR files in the lib/ext directory of the JRE. The class path: classes, including classes in JAR files, on paths specified by the system property java.class.path. .... ... The precedence list tells you, for example, that the class path is searched only if a class to be loaded hasn't been found among the classes in rt.jar, i18n.jar or the installed extensions. ... The Java 1.2 platform uses a new delegation model for loading classes. The basic idea is that every class loader has a "parent" class loader. When loading a class, a class loader first "delegates" the search for the class to its parent class loader before attempting to find the class itself. ... 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. 5:28:53 PM