Caffeine Induced

I used C++ for years and I was a freak about making the directory structure consistent for all source code. It really annoyed me when people put files in random places or tried to cram 12 public classes in a single file. Yuck. I think the fact that Java enforces a heuristic like one public class per file is great.

I think an even greater advantage for Java is that it forces your physical directory structure to mimic your logical package structure. What a great idea - consistency. Some might argue that this is taking their "flexibility" away, but who need's to waste mental bandwidth thinking like things like this...? And who wants to put up with the situation where people make bad decisions about source code directory structure (and then you either have to live with it or fix it)...? The Java way is better.

I'm sure this simple constraint makes life much easier on the ide vendors too. Its real easy to tell my IDE - "this is my root source directory, you'll find my package structure underneath this, as well as all my sources..."

All in all, the designers of the Java language chose simplicity over "options" at the language level - I think this is a good thing. Sure you can implement any XYZ concept as a language feature, but should you...? Probably not. Java's approach is to favor implemention of this concept in a class library. This is why the grammar for Java is a fraction of the size of the grammar for C++ (which means Java parsers have much less ambiguity to deal with). The fact that the language is so small and tight makes it easier for development tools to deal with Java source.

----------------

I'm going to open a bug on this so we don't forget about it. There are a few places in our code where we've had to explicitly set the classloader to get around a classloader bug in WebStart.

To find all of these places, do a search for the following in our codebase (its mostly done in areas where we're looking up an object from JNDI on the client):

Thread.currentThread().setContextClassLoader The bug in WebStart only occurs when the console output is turned OFF (if the console is on, you won't see the errors - dangerous).

For some background on this, issue see:

http://forum.java.sun.com/thread.jsp?forum=38&thread=301640 http://forum.java.sun.com/thread.jsp?forum=38&thread=71223

------- Additional Comments From Lance Hankins 2003-01-22 16:37 -------

For now this has been reduced to a single place in the code where we have to call:

Thread.currentThread().setContextClassLoader

This is now called in the initialize() method of AbstractFSXMain (for both the main thread and the main Swing event thread).

Once a new version of Webstart is released (JDK 1.4.2..?), we can test to see if this is still neccessary.

-----------------

The workaround we did is this (called a single time from the startup of our application) :

  /**
   * this method is a fix for a Webstart bug - see Bugzilla Bug #1485
   */

   protected void fixWebStartClassLoaderIssue()
   {
      final Runnable setClassLoaderCmd = new Runnable(){
         public void run()
         {
            //--- use some project specific class with the right classloader here...
            Thread.currentThread().setContextClassLoader(SomeClass.class.getClassLoader());
         }
      };

 
      //--- this will execute in the main thread...
      setClassLoaderCmd.run();
 
      //--- this will execute in the main Swing event thread...
      SwingUtilities.invokeLater(setClassLoaderCmd);
   }