harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Possibly incorrect property settings in M10?
Date Fri, 19 Jun 2009 09:52:20 GMT
Nathan Beyer wrote:
> 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:
>>> <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


Mime
View raw message