So I submitted two bugs to Sun regarding the 1.4 JDK. One is more important than the other.
The first bug has to do with how the java.lang.reflect.Proxy class works. The Proxy class is really handy if you ever need to do multiple inheritance or other nifty Java tricks. If you want to know more you can google or look at the decent article over at devx.com.

The problem is that when you pass an implementation of Proxy from one jvm to another, you get some ClassNotFoundExceptions because the contract interface is in the application classloader and not the system class loader. This is because there is a special classloader for Proxy classes that does not use the current classloader, I suspect it uses the system classloader.

This was causing some major problems in a project I was involved in two years ago because we used Proxy classes all over the place for our transfer object. It was actually the brainchild of this developer I work with, Ali, who came up with a handy way of creating stateful transfer objects by just defining the interface class. This worked great until we tried passing the Proxy transfer objects from JUnit to the web or ejb container. It started blowing up.

I ended up patching the custom ObjectInputStream that BEA used for WebLogic and we got it to work, but I couldn't patch the default JDK/JRE ObjectInputStream used to serialize/deserialize. I submitted a bug to Sun (208933) so they could correct it. It's been about two years and the new 1.5/5.0 JDK has come out and this bug still exists. It's pretty frustrating. Had this been apache or struts or jboss or something and a rather serious bug existed, at least I could fix it locally. I can't wait until the Apache OS JDK comes out so we don't have to deal with those slackers at Sun.

Looking at the top 25 bugs, it looks like there are quite a few problems lingering around.

Oh yeah, my other bug was the continued usage of deprecated Calendar/Date methods in the zip package. A slightly cosmetic bug, but could be serious considering that the deprecated Date methods synchronize on an internal static Calendar. So every thread using the deprecated Date constructor will block. This can be bad when your app uses this to check date diffs (like WebLogic used to do to see if JSP/Servlets have changed in a specific interval).