Bugs in the JDK
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 inteface 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).
I was always a little leery of friendster.com and sites like that. I'm married so I wasn't looking for online dating and stuff. And I seemed to be able to schedule my life and meet with friends without needing the help of a "social networking" site.
The other day (after demoing TIBCO's really cool Ajax framework) someone sent me an invite to LinkedIn.com. I ignored it at first, but this guy also sent an invite to a couple co-workers who then sent me new invites.
So I succumbed and joined up. LinkedIn isn't a social networking site, it's a business networking site. I've only been playing around with it for a few days, but it's really interesting. I wish we had this back when I was doing consulting. It would have made finding contracts a lot easier.
It's interesting how many people you end up being linked to. No links to Bill Gates or Torvalds yet, but I'm still hoping. My goal now is to get close to someone who can hire me to google.
LinkedIn is free and everything but I suspect they'll start charging soon for some of the advanced features. I just wish they would get a good graphical representation of the links between contacts. It's sad, but even though I crank out tons of back-end code day in and day out, I'm a sucker for a good graphic. You can never pay too much for a good graphic design.
Next post is about why the bugs I submit to Sun never get fixed (two years and counting).