harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Beyer <ndbe...@apache.org>
Subject Re: Possibly incorrect property settings in M10?
Date Wed, 17 Jun 2009 03:57:59 GMT
On Tue, Jun 16, 2009 at 5:55 AM, Oliver Deakin <oliver.deakin@googlemail.com
> wrote:

> sebb wrote:
>
>> On 16/06/2009, Nathan Beyer <ndbeyer@apache.org> wrote:
>>
>>
>>> On Mon, Jun 15, 2009 at 5:37 PM, sebb<sebbaz@gmail.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message