Just some time before Sun Microsoystem launches their greatest Java 5.0 edition, they released maintenance version of their 1.4 line: Java 1.4.2_05. It consists of some bugsfixings listed here.
Sun’s marketing department don’t seem to know their backsides from their elbows when it comes to Java version numbers. They started with plain old Java 1.X until (and including) Java 1.1. Then they decided they’d launch “Java 2”, but instead of calling it something like 2.0, they called it “Java 2 Version 1.2”.
This crazy numbering scheme has lasted through to the current 1.4.X releases, but now Sun have decided that Java 2 should, er, *still* be called Java 2, but have a “sub-version” of 5.0 (my guess is that they think that this means going from sub-version 4 (aka 1.4.X) to sub-version 5 (ala 5.0), but that of course is somewhat deranged in the real world.
Perhaps the gun they’re shooting their foot off with isn’t quite enough, because in the Looney Tunes world of Java version numbering, I was *really* expecting “Java 3 Release 5.0″…
Isn’t this version number story about the same as that of Solaris? I recall Solaris 10 being really SunOS 5.10, and SunOS 5 was really SunOS 2.5, or something like that.
Yet it could have been even worse. Sun could have chosen a naming scheme similar to the application that I have developed 😀
The 1.x versioning actually does make sense. 1.5 is the 5th technology revision of the language, but it retains compatibility with code written for 1.0. Any and all Java code written circa 1995 and compiled to bytecode with the 1.0 bytecode compiler will in fact run without modification via the 1.5 JVM. Version 2.0, if it ever occurs, would imply a compatibility break with the published library APIs and/or the bytecode format.
> Java has never had 100% compatiblity between versions
Can you provide an example or are you confusing what is meant by compatibility? The additional features/libraries used in code written for the 1.4 spec might not work on a 1.0 compiler, but as far as I know each subsequent version will run any bytecode from a previous version without a recompile. The APIs for the core Java libraries are often extended and the internals may be changed, but all the old API decisions still exist. That choice for compatibility has left each version of Java to inherit the API mistakes made in the versions preceeding it, but changing those comes at the cost of breaking existing bytecode. So I think you’re mistaken that Sun has ever broken compatibility.
I found this, too. Some graphical app did not work any more after updating to 1.4. As no source code for the charting package (I think that was it) was available. So this app only works with the older runtime. I did no extensive tests to find the real sourcce of the problem. But it definately did not “just run”.
For all those open-source fanboy Sun-haters, you should read the list of bugs fixed. There are hundreds. Commercial software vendors discovered bugfixing a long time before Open Source existed.
The APIs for the core Java libraries are often extended and the internals may be changed, but all the old API decisions still exist. That choice for compatibility has left each version of Java to inherit the API mistakes made in the versions preceeding it
Does this mean that Java 5 will still run applications which use the old event handling system from Java 1?
thanx, although Sun tends to put their foot in their mouth at times (example: “we have no linux position”) they tend to release good software. The API’s for java are the best documentation for any programming language. project looking glass is also an amazing piece of software (btw, if you dont like looking glass deal, Apple and Microsoft have plenty of bells and whisles on their desktops and the number will only grow). openoffice has problems, hopefully they will be ironed out by the 2.0 release.
Just a quick note: I downloaded Beta 2 for Linux x86, and relative to 1.4.2 (stock Suse 9.0), it just flies! I tried running Jedit 4.1, which is sluggish under 1.4.2, and it feels just like a native (e.g. Qt, not GTK—no flames please) app. I’m definitely impressed. Even Eclipse 3.0 seems to benefit from the new jre—it “feels” more or less like a regular GTK app.
I’d be curious to know whether other people have had similar impressions.
One bad thing they did not fix completely is font handling. Now I can access my system fonts (e.g. Vera & co.), but my fontconfig settings are not picked up (e.g. there is no subpixel decimation).
The Java 1.5 release candidate is supposed to come out in August, and the final release is 30 September. I read it somewhere on Sun’s site and was surprised because I thought that 1.5 was due to imminent release with all the fuss being made at SunOne
Some graphical app did not work any more after updating to 1.4. As no source code for the charting package (I think that was it) was available.
Are you sure it was not using something from the sun.(or other internal) package?
As that is internal (and thus should not be used), it does change between versions (as I found out when upgrading from 1.3, luckly what broke was a none-vital feature).
I had a problem with early 1.4 jre. There was a bug under windows which crashed when trying to read a file into a binary array, but it worked on linux and every other platform.
I never did find out if it was fixed. Most backward compatibility problems with Java that I’ve had, have been all about new bugs rather than incompatibilities.
I havn’t had as much of a speedup as you with 1.5, but it’s still significant. The top speed for me comes in qt as well. Before the 2nd place would be gtk, with swing coming in at a very distant 3rd. I only use one swing based application on a regular basis, and it’s pretty small (just a flash card program). But I’d say that the speed of the menus, and general rendering with it is now comparable to gtk2 based applications since upgrading to 1.5.
> Can you provide an example or are you confusing what is meant by compatibility?
One example would be the change in the set of exceptions that can be thrown by Sockets between 1.3 and 1.4. This can lead to a silent failure in the error handling path of code compiled against the older JVM.
This was a huge, huge pain both to discover what was going on and then to find weak and sickly workarounds. I can’t wait to get this sucker into production.
Yes, I assume you are implying Java V1.5 and not V5
Java 1.5 is aka Java 5
No. Sun *is* referring to beta 2 of 1.5.0 as “Java 2 Platform, Standard Edition 5.0 Beta 2”: http://java.sun.com/j2se/1.5.0/download.jsp.
They will use 5.0 for the next, 1.5.
http://www.sun.com/smi/press/sunflash/2004-06/sunflash.20040628.3.h…
Sun’s marketing department don’t seem to know their backsides from their elbows when it comes to Java version numbers. They started with plain old Java 1.X until (and including) Java 1.1. Then they decided they’d launch “Java 2”, but instead of calling it something like 2.0, they called it “Java 2 Version 1.2”.
This crazy numbering scheme has lasted through to the current 1.4.X releases, but now Sun have decided that Java 2 should, er, *still* be called Java 2, but have a “sub-version” of 5.0 (my guess is that they think that this means going from sub-version 4 (aka 1.4.X) to sub-version 5 (ala 5.0), but that of course is somewhat deranged in the real world.
Perhaps the gun they’re shooting their foot off with isn’t quite enough, because in the Looney Tunes world of Java version numbering, I was *really* expecting “Java 3 Release 5.0″…
Isn’t this version number story about the same as that of Solaris? I recall Solaris 10 being really SunOS 5.10, and SunOS 5 was really SunOS 2.5, or something like that.
Yet it could have been even worse. Sun could have chosen a naming scheme similar to the application that I have developed 😀
Does anyone know the release date for the new version 1.5?
No, it wasn’t available 2 days ago so its relatively new.
could be much worse….they could call it Java 2004 Standard edition….. or Java XP
Maybe it’s the same person who design Swing and handle the version number … ;o)
(don’t flame me it’s a joke !!)
Not sure about Solaris 10, but IIRC Solaris 6, 7, and 8 was really SunOS 2.6, 2.7, and 2.8.
-G
The 1.x versioning actually does make sense. 1.5 is the 5th technology revision of the language, but it retains compatibility with code written for 1.0. Any and all Java code written circa 1995 and compiled to bytecode with the 1.0 bytecode compiler will in fact run without modification via the 1.5 JVM. Version 2.0, if it ever occurs, would imply a compatibility break with the published library APIs and/or the bytecode format.
Ooops… My bad… I read that as 1.4.1_05
Interesting, I have 1.4.2_03, and a quick Update from my Java Control Panel says I have the latest version. So much for trusting auto-updaters…
Java 1 = Java 1
Java 1.2 = Java 2
Java 1.3 and 1.4 were Java 2
but if you’d keep on counting it’d be:
Java 1.3 = Java 3
Java 1.4 = Java 4
Java 1.5 = Java 5
So what happened to 1.1 ?
1.1 is a quantum superposition of 1 and 2.
Dream on. while the newest java is quite compatible with older stuff -Java has never had 100% compatiblity between versions-AFAIK…..
I think there is too much hate for Java and for Sun… I think you guys should settle down. Sun is pretty good company and Java is a very nice language.
> Java has never had 100% compatiblity between versions
Can you provide an example or are you confusing what is meant by compatibility? The additional features/libraries used in code written for the 1.4 spec might not work on a 1.0 compiler, but as far as I know each subsequent version will run any bytecode from a previous version without a recompile. The APIs for the core Java libraries are often extended and the internals may be changed, but all the old API decisions still exist. That choice for compatibility has left each version of Java to inherit the API mistakes made in the versions preceeding it, but changing those comes at the cost of breaking existing bytecode. So I think you’re mistaken that Sun has ever broken compatibility.
> Can you provide an example or are you confusing
I found this, too. Some graphical app did not work any more after updating to 1.4. As no source code for the charting package (I think that was it) was available. So this app only works with the older runtime. I did no extensive tests to find the real sourcce of the problem. But it definately did not “just run”.
For all those open-source fanboy Sun-haters, you should read the list of bugs fixed. There are hundreds. Commercial software vendors discovered bugfixing a long time before Open Source existed.
The APIs for the core Java libraries are often extended and the internals may be changed, but all the old API decisions still exist. That choice for compatibility has left each version of Java to inherit the API mistakes made in the versions preceeding it
Does this mean that Java 5 will still run applications which use the old event handling system from Java 1?
thanx, although Sun tends to put their foot in their mouth at times (example: “we have no linux position”) they tend to release good software. The API’s for java are the best documentation for any programming language. project looking glass is also an amazing piece of software (btw, if you dont like looking glass deal, Apple and Microsoft have plenty of bells and whisles on their desktops and the number will only grow). openoffice has problems, hopefully they will be ironed out by the 2.0 release.
Why Windows 4.0 = 95? (Old joke, I know.)
Commercial software vendors discovered bugfixing a long time before Open Source existed.
… except that Open Source software existed way before commercial software. Sorry for being so off-topic.
PS.: I guess Java 2004 would be a much better vesioning scheme than any of this inflation thing…
Just a quick note: I downloaded Beta 2 for Linux x86, and relative to 1.4.2 (stock Suse 9.0), it just flies! I tried running Jedit 4.1, which is sluggish under 1.4.2, and it feels just like a native (e.g. Qt, not GTK—no flames please) app. I’m definitely impressed. Even Eclipse 3.0 seems to benefit from the new jre—it “feels” more or less like a regular GTK app.
I’d be curious to know whether other people have had similar impressions.
One bad thing they did not fix completely is font handling. Now I can access my system fonts (e.g. Vera & co.), but my fontconfig settings are not picked up (e.g. there is no subpixel decimation).
Just my $.000002 on a Friday evening…
M
The Java 1.5 release candidate is supposed to come out in August, and the final release is 30 September. I read it somewhere on Sun’s site and was surprised because I thought that 1.5 was due to imminent release with all the fuss being made at SunOne
Some graphical app did not work any more after updating to 1.4. As no source code for the charting package (I think that was it) was available.
Are you sure it was not using something from the sun.(or other internal) package?
As that is internal (and thus should not be used), it does change between versions (as I found out when upgrading from 1.3, luckly what broke was a none-vital feature).
I had a problem with early 1.4 jre. There was a bug under windows which crashed when trying to read a file into a binary array, but it worked on linux and every other platform.
I never did find out if it was fixed. Most backward compatibility problems with Java that I’ve had, have been all about new bugs rather than incompatibilities.
I havn’t had as much of a speedup as you with 1.5, but it’s still significant. The top speed for me comes in qt as well. Before the 2nd place would be gtk, with swing coming in at a very distant 3rd. I only use one swing based application on a regular basis, and it’s pretty small (just a flash card program). But I’d say that the speed of the menus, and general rendering with it is now comparable to gtk2 based applications since upgrading to 1.5.
“Can you provide an example or are you confusing what is meant by compatibility? ”
Off the top of my head, IBM’s aglets. I’ve not tried it, but they have a notice saying that it won’t work with Java2.