version number [Re: changeset in /hg/icedtea6: 2008-06-11 Lillian Angel <langel at re...]

[Mark Wielaard]

Hi Matthias,

On Thu, 2008-06-12 at 11:35 +0200, Matthias Klose wrote:
> Lillian Angel schrieb:
> > changeset 485da23424a2 in /hg/icedtea6
> > details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=485da23424a2
> > description:
> > 	2008-06-11  Lillian Angel  <langel at redhat.com>
> > 
> > 	        * Makefile.am: Added JDK_UPDATE_VERSION to environment. Some applets,
> > 	        like the Sun's verify Java version applet, check for the "_" in the
> > 	        version string. Our version string format is now correct:
> > 	        java version "1.6.0_0"
> > 	        OpenJDK  Runtime Environment (build 1.6.0_0-b10)
> > 	        OpenJDK Server VM (build 1.6.0_0-b10, mixed mode)
> > 	        * Makefile.in: Regenerated.
> 
> Do we really want this? According to
> http://java.sun.com/javase/6/webnotes/version-6.html
> the underscore isn't mentioned at all. Is this further specified?
> 
> This schema also differs with the Java 6 version number, which displays
> "1.6.0_06" for the version, and "1.6.0_06-b02" for the full version. Apparently
> "b02"is used here for the build number, while for OpenJDK the "bxx" part is used
> as service release / new code drop.

This actually came from the discussion you and I had on irc. As you
pointed out one of the first applets people try after installing
openjdk/icedtea/gcjwebplugin is the test applet one from sun. To verify
that everything installed fine. That applet fails very ungracefully
since it assumes the version number from the java.version system
property has an underscore in it. Apparently applications use this to
check whether you are running the latest "update version". And they die
horribly if they don't see the "update number" in the java.version
property as an underscore-number pair (basically stuffing an empty
string into new Integer and die when that doesn't parse). Of course
without the source code it is somewhat hard, maybe we can find someone
that could find the code for this particular application. But people
will want to run existing applications, so even if the code makes wrong
assumptions and we can make them work anyway it is a good idea to add
the support.

Some more analysis is also in this fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=449959

I don't know if "0" is a good update number to use, or whether other
applications expect an higher version there. It would be best if
applications detected openjdk as the latest and greatest available.

Cheers,

Mark