On Tue, Jun 16, 2009 at 5:55 AM, Oliver Deakin <[email protected] > wrote:
> sebb wrote: > >> On 16/06/2009, Nathan Beyer <[email protected]> wrote: >> >> >>> On Mon, Jun 15, 2009 at 5:37 PM, sebb<[email protected]> wrote: >>> > Harmony M10 reports the following properties: >>> > >>> > java.class.version=50.0 >>> >>> >>> Just checking, but you did use the 1.5 artifacts and not the 1.6 ones, >>> correct? That should be 49.0 for the 1.5 artifacts. >>> >>> >> >> I used the link "Apache Harmony 5.0M10 JDK for 32-bit Windows" from >> http://harmony.apache.org/download.cgi. >> >> SHA1 = 3e5e00e9e01c864e2c2e578016703899cbb336a5 >> >> java -version shows: >> >> Apache Harmony Launcher : (c) Copyright 1991, 2009 The Apache Software >> Foundation or its licensors, as applicable. >> java version "1.5.0" >> pre-alpha : not complete or compatible >> svn = r782693, (Jun 12 2009), Windows/ia32/msvc 1310, release build >> http://harmony.apache.org >> >> BTW, the same applied to the previous version I tried: >> >> Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software >> Foundatio >> n or its licensors, as applicable. >> java version "1.5.0" >> pre-alpha : not complete or compatible >> svn = r761593, (Apr 3 2009), Windows/ia32/msvc 1310, release build >> http://harmony.apache.org >> >> >> > > I see the same thing - java.class.version is 50.0. I see in > vm_properties.cpp of drlvm we do the following: > > properties.set_new("java.class.version", EXPAND(CLASSFILE_MAJOR_MAX) "." > EXPAND(CLASSFILE_MINOR_MAX)); > > where CLASSFILE_MAJOR_MAX is set to 50. I think that's because drlvm > supports Java 6 class file formats even in the HEAD (5.0) branch. > > Should the property indicate the class level supported by the VM (as it is > set by the VM) or the actual class library API level? > The spec defines this property as: "java.class.version - Java class format > version number" Good point - I'm not sure exactly what this means. However, even if DRLVM could handle that class file format, would most classes blow up eventually because they're linked to some Java 6 API. In this case, I'm tempted to stick with the behavior of the RI and have the property line up with the class library. > > > I do notice that we set java.specification.version, java.version and > java.runtime.version properties to indicate we are running a Java 1.5 class > library. Perhaps leaving java.class.version at 50.0 as an indication that > classes with 50.0 format can be executed on those builds makes sense. It's > an indication of the acceptable maximum class file format version rather > than the API level supported (which is defined by the other properties > mentioned). I would be inclined to leave it as is. > > Regards, > Oliver > > > > java.vm.version=11.2.0 >>> >>> >>> That's the version of DRLVM. Why, I don't know, but that's what it is. >>> What do you think it should be? >>> >>> >> >> For the Sun JVMs, it is e.g. >> >> java.vm.version=1.5.0_18-b02 >> > In this case, I think we're fine, as the spec (javadoc) is clearer. "java.vm.version Java Virtual Machine implementation version" Additionally, there is a "java.vm.specification.version", which I would expect to be "1.5.0". -Nathan > >> >> >>> > >>> > I would expect the class version to be 49.0, and the java.vm.version >>> > looks rather odd. >>> > Should I raise a JIRA for these? >>> > >>> >>> >>> >> >> >> > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > >
