Nathan Beyer wrote:
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:
<snip!>
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.
That's the question I was asking myself as well - is it enough that we
make it clear we're only supplying 1.5 APIs via the other properties I
mention below, but we are capable of reading classes compiled with Java
6 where only Java 5 level APIs are required? My only concern is that
this property might be a little misleading if we leave it as 50.0.
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
Im starting to wonder if these properties are set to the correct values
in the Java 6 federated build. I might give that a test today if I have
time...
Regards,
Oliver
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
--
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
