Hey Gosling: This is why we don’t use Java 5.0 yet!
Whenever there is a major JDK update everyone on the Sun Microsystems side seems to love to beat the drum of upgrading. This leaves developers in a situation where they love the new features of the new JDK but quickly find out the rest of the world isn’t so quick to follow them. Recently, even James Gosling argued with developers about moving to JDK 5.0, stating that, “Don’t wait for a .1 release… We’re not going to do it because 5.0 is very stable. Don’t wait just get the .0 release.”.
Worse, the platform of choice of Java developers, Apple Mac OSX, has just released a new update to their J2SE 5.0 Developer Preview that finally changes that magic symbolic link to make JDK 5 perferred (before you had 5.0 but all apps ran 1.4.2 by default).
Well, after having just got burned again by coding to JDK 5 with the StringBuilder, the autoboxing, generics and the printf() for a friend only to find out the deploy envionment doesn’t support JDK 5 yet, and having to spend two days changing by code, (and feeling the pain I cringed at after reading Kirill Grouchnikov’s entry on Java.net in July ) I created the following list of things that must occur before people stop coding in JDK 1.4.2:
1. Sun’s own tools, such as NetBeans, Studio Creator, and Enterprise Studio must not ask for a JDK 1.4.2 or refuse to install and in the future, they should not recommend people upgrade their JDK UNTIL Sun’s tools themselves can at least run with the latest JDK, not a year after the JDK’s release.
2. All third-party vendors that have shared VMs across their Tomcat hosting systems, such as GoDaddy.com, must give us good information on what JDK is installed and when it will be upgraded.
3. Someone must write a NetBeans or Eclipse plug-in to reverse all trivial JDK 5.0 uses such as auto-boxing and StringBuilder. Don’t write, I know IntelliJ already does this and provides intentions to correct this, and that is why all my opensource and professional development uses IntelliJ and provide licenses to others who work with me. Also, I am aware of RetroWeaver, but I’ve heard it’s success is uneven.
Until these things happen, I’ll just have to write to JDK 1.4.2 and try not to think how easy .Net developers had it when upgrading to the recently released .Net 2 Framework. Yes, Java runs everywhere, but not evenly.
December 20th, 2005 at 11:23 am
So you’re somewhat angry because a friend ported his code to 5.0 just to find that his deployment environment doesn’t support 5.0? Shouldn’t he have checked this deployment environment *first*?!
Also, all the new Sun development tools work perfectly fine with 5.0 so that argument is a non-issue.
As for 3rd party vendors such as GoDaddy not telling you which VM they are running, you can easily find out the VM versions programmatically with a single line of Java code. If you want to find out when they’re going to upgrade to a newer release, well, call them. You’re the one paying them, they answer to you.
*Moffin
December 20th, 2005 at 12:46 pm
The Glazed Lists folks discovered an easy way of using the 5.0 language features and running the code on 1.4: http://www.publicobject.com/glazedlists/documentation/Generics_and_Java_1.4_with_one_codebase.pdf
December 20th, 2005 at 12:49 pm
Hey Mozilla Moffin!
I am so impressed by the quality of the people that post responses, from Alex Tkachman to James Governor to Patrick Chanezon to all the Sun folks. It’s almost like I somehow found a IP Filter setting in Solaris 10 to let in only the brighest people. :-)
Studio Enterprise & Creator require a 1.4.2 to install. Afterward, you can select to compile against 5.0, but you must first have 1.4.2. I know because just today I had to use the -is:java flag on installcreator.sh since I only have 5.0 JDK visible in my JAVA_HOME.
Also, it is true that NetBeans 5.0 Beta does use 5.0 JDK, but that is now (and Beta) whereas my argument is that the tools should be up to the same JDK level as the latest release. It was a good year before we are just now seeing 5.0 JDK level tools from the big guns show up.
Keep in mind I’m not talking about writing for JDK 5.0 in the IDE (with annotation support and all that) which NetBeans & Eclipse had early, but actually using the JDK itself.
There was an article recently on Java.net about people being reluctant to run plug-ins that relied on JDK 5.0, so the reservations are pretty deep. However, it took me 10 minutes of Googling to recall Grouchnikov’s posting so I’m not going to go looking :-)
December 20th, 2005 at 6:31 pm
I think there is a more compelling reason preventing an upgrade to jdk5 now: customers… I don’t have a single customer running jdk5, having any application server or development environment jdk5-compliant. Simply, there is no market demand so far. When there will be? My opinon is when EJB 3.0 compatible app servers will be widespread, because I think new EJB specs are going to be a driver for innovation in the Java enterprise market, which has been a bit dormant recently (not in terms of buzzwords, but real innovation).
December 20th, 2005 at 11:37 pm
[...] Brandon Werner » Blog Archive » Hey Gosling: This is why we don’t use Java 5.0 yet! » Whenever there is a major JDK update everyone on the Sun Microsystems side seems to love to beat the drum of upgrading. This leaves developers in a situation where they love the new features of the new JDK but quickly find out the rest of the world isn’t [...]
December 21st, 2005 at 10:43 am
Eclipse has settings to parse Java 5 source-code but emit Java 1.4 classes. But I must admit I haven’t tried it out yet.
December 21st, 2005 at 2:10 pm
“the platform of choice of Java developers, Apple Mac OSX”
Really??? I’m not saying it sucks - I really don’t know anything about it. But that’s because I don’t know ANYBODY developing on it. Am I living in a bubble?
December 22nd, 2005 at 1:20 am
We migrated from 1.4.2 to jdk1.5 successfully. jboss4.0.3 has ejb3.0 support.
December 22nd, 2005 at 7:19 am
Hi Mark,
I have looked for such wonderful Eclipse settings, that allow for 1.5 source code with generics, enums, annotations, java.util.concurrent.*, etc. and really give us the 1.4 bytecode at the end. I don’t think that this is possible.
If you use “Compiler compliance level “5.0″ you CANNOT set the “Generated .class files compatibility” to “1.4″! Otherwise the Eclipse people would have to provide a COMPLETE Java 5 to 1.4 backport…
My current solution right now is to use the new OS project Retrotranslator if we need one source for both 1.5 and 1.4.
December 22nd, 2005 at 10:21 am
[...] Brandon Werner » Blog Archive » Hey Gosling: This is why we don’t use Java 5.0 yet! Whenever there is a major JDK update everyone on the Sun Microsystems side seems to love to beat the drum of upgrading. This leaves developers in a situation where they love the new features of the new JDK but quickly find out the rest of the world isn’ (tags: java5.0 java) [...]
January 6th, 2006 at 9:01 pm
The real reason “why not 1.5…” for our product is that it must run on the Mac OS X, but not necessarily on Tiger.
1.5 supported on Tiger only and nobody knows when all the Mac owners will migrate to Tiger (the migration is not free)
January 6th, 2006 at 11:24 pm
That is a damn good point Dmitry, Apple’s insistance on only providing Java 5 to upgraded OSes only smacks Sun & the idea of Java in the face.. hard. Java is platform independent, but Apple is the only entity that controls it’s Java distro (because of PowerPC compilation I’m sure) and uses it as leverage.
I’m certain when Apple moves to the Intel platform Sun will have a UNIX build of Java5 for Mac no matter what OS is running. Since Apple is abandoning Cooca Java binding going forward, there is no reason for deeply customized Apple distros or .jars anymore.
February 9th, 2006 at 8:36 am
I use a personally backported version of StringBuilder and other classes for java 1.3/1.4 in my work code (in a non java packages), because I must support legacy java, but still need flexibility/speed; Sun made plenty of dumb mistakes in the past *, so should expect this! It is not hard to backport basic classes like this (without 1.5 extras) if you have the 1.5 JDK (with src.jar), try it. I doubt I will release this openly given license concerns.
IMHO A synchronized string buffer is a really dumb idea, I doubt that it is genuinely useful or safe in a multi-threaded environment, given that text sequencing could cause some nasty bugs and there are more efficient/safer ways to handle thread safety, e.g. synchronizing on the buffer object!
I also have major gripes about classes having private rather than protected values, so making subclassing a pain (e.g. java.util.* and java.io.*), but is with little if any security benefit, so yet more class source code copying has to be done!
May 23rd, 2006 at 6:45 pm
weblogic 8.1 is not compatible with jdk 1.5. I use jdk1.42 and getting String builder related error when ” ” are used for strings. Kindly Help