Kevin Burton’s NEW FeedBlog

Looks like SUN Microsystems might finally come around and see the light with regard to Open Source java.

This is a very important decision for the company and one I’ve been expecting for a long time. For about 5 years (since I worked with the Jakarta group) I’ve been saying that either Java will become OSS or it will die. For every SUN engineer or executive who argued with me that open Java would never happen: told ya so!

Open Source software in the server world is critical. In my mind Debian rules the day. Not to be undone there is actually a Debian GNU/Solaris (now called Nexenta) I think which provides all the stability and ease of use of Debian with the power of Solaris. I’ve really been wanting to get an extra machine so I can play with it for a bit.

Python is the Java of Open Source (at least for now). It doesn’t provide all the bells and whistles of Java but it nails fit and finish.

There’s a yin and yang of proprietary vs open software. Proprietary software often has a lot of bells and whistles, has support for the latest hardware and cross industry standards. Open software however seems to have a lot more polish than proprietary software. Since there aren’t any barriers to entry real itches can be scratched.

I’ve personally wanted to dive in and fix issues with Java but SUN prevented any of my contributions. I even went so far as to try to give patches to SUN engineers for javadoc, the standard library, etc but was prevented.

If they do this right Java might really start to be an amazing language even besting python in areas where it currently shines. It won’t be easy but there’s still a lot of potential here.

Off the top of my head there are some big issues that need to be fixed.

1. I want a Debian package for Java in the main APT line. This should include packages for the standard OSS Java projects like Xerces, Tomcat, etc.

2. The standard library should be broken out into separate jars. Its amazingly stupid that I can’t update individual packages within the standard library without updating the whole VM. I can’t run JDK 1.5 because of a bug in the SSL library but I need the regexp package from 1.5 because of a bug fix. If the regexp package were released in an individual package I could just upgrade my 1.4 install.

3. The CLASSPATH variable should allow directory names not just file names. I think Zawodny says it best:

Anyway, to make a long story short, Sun did something rather stupid. I wasted a good hour because I should have put an explicit reference to the jar file in my $CLASSPATH. It’s not sufficient to simply drop the jar file into one of the directories specified in $CLASSPATH.

…

Do the morons at Sun (one of the oldest Unix companies!) not realize how Unix path variables normally work? Paths specify directory names, not zip, tar, jar, or any other type of archive files.

4. It shouldn’t take 30 seconds to boot the JVM on modern hardware. I should be able to run Java as a CGI if I wanted. This prevents real world use because the 30 second barrier is too annoying for most apps.

5. I need to be able to read environment variables. No more stupid excuses like environment variables aren’t portable because of OS 9. I don’t care about portable code. Java isn’t portable anyway. I care that my code runs well on Linux/UNIX.

…

I’m going to keep updating this blog post with annoying java problems that should have been fixed years ago. I’m sure I can easily get to 20-30… If you guys think of any add them in the comments.