harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [drlvm] DRLVM should accept Java6 classes now
Date Fri, 07 Sep 2007 09:40:10 GMT
Tim Ellison wrote:
> Yuri Dolgov wrote:
>>> we can make this constant definable by the build.
>> That's a great idea. I agree.
> 
> Would it be too expensive as a runtime check? i.e ask the classlib at
> start-up if the VM should behave like Java 5 or Java 6, then we don't
> even have to produce separate VM builds.

I don't think it would be expensive in any way. This constant 
CLASSFILE_MAJOR_MAX is currently used only in 2 places, to check that 
class file version is supported by VM, and to define java.class.version 
property value on startup.

This property could be defined by classlib code, and VM would use its 
value in class loader instead of hardcoded class version.

>> On 9/6/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>> Egor Pasko wrote:
>>>> On the 0x349 day of Apache Harmony Gregory Shimansky wrote:
>>>>> Yuri Dolgov wrote:
>>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found
non
>>>>>>> features specific to VM except for a small change in reflection
API
>>> [2].
>>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>>> Yes, that's fine. But why don't we just put this in Java 6 branch?
I
>>>>>> understand
>>>>>> that our VM works fine with Java 6 classes, but what about classlib
>>> and JIT?
>>>>>> I think that throwing UnsupportedClassVersionError is just a tool
>>>>>> which
>>>>>> help to avoid unpredictable results.
>>>>> Well, because there isn't a Java6 branch for VM. And I don't think
>>>>> that a change in 1 line deserves to create one.
>>>> +1
>>>> alternatively: if it is one liner, we can make make it an option in the
>>> build.
>>>
>>> After the patch that I've committed at 572698 the class version is
>>> controlled by a single constant CLASSFILE_MAJOR_MAX in Class.h. Yes I
>>> think we can make this constant definable by the build.
>>>
>>>>>> On 9/6/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
>>>>>>> Yuri Dolgov wrote:
>>>>>>>> Hello Gregory,
>>>>>>>>
>>>>>>>> I'm not sure what is the reason to support classes with version
50
>>> if
>>>>>>> don't
>>>>>>>> support
>>>>>>>> Java 6 features? Maybe it worth to make this changes in separate
>>> Java 6
>>>>>>>> branch to
>>>>>>>> prevent confisions?
>>>>>>> Looking at the Sun's list of enhancements for Java6 [1] I found
non
>>>>>>> features specific to VM except for a small change in reflection
API
>>> [2].
>>>>>>> So it seems to me that VM in Java5 and Java6 can be the same.
>>>>>>>
>>>>>>> [1] http://java.sun.com/javase/6/webnotes/features.html
>>>>>>> [2]
>>>>>>>
>>>>>>>
>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>> On 9/5/07, Gregory Shimansky <gshimansky@gmail.com>
wrote:
>>>>>>>>> Stepan Mishura wrote:
>>>>>>>>>> On 9/4/07, Gregory Shimansky wrote:
>>>>>>>>>>> Hello
>>>>>>>>>>>
>>>>>>>>>>> As of revision 572698 DRLVM should not throw
>>> UnsupportedClassVersion
>>>>>>>>>>> when it sees a class file compiled with Java6
compiler (or with
>>>>>>> -target
>>>>>>>>>>> 1.6 by ECJ 3.3). These class files should work
with no problems
>>> with
>>>>>>>>> DRLVM.
>>>>>>>>>> Sould we create a java6 branch for DRL VM (as we
did for classlib)
>>> and
>>>>>>>>>> move your update to the branch?
>>>>>>>>> I don't think this deserves a real branch. The fact that
VM accepts
>>>>>>>>> classes of version 50 doesn't mean it is Java6 compliant.
It also
>>>>>>>>> doesn't make it non-Java5 VM in any way.
>>>>>>>>>
>>>>>>>>> On the other hand, if we make changes like in [1] it
may break
>>>>>>>>> compatibility with older Java5 code, and in such case
we'll maybe
>>> want
>>>>>>>>> to create a separate branch.
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>>>
>>> http://java.sun.com/javase/6/docs/technotes/guides/reflection/enhancements.html
>>>>>>>>>>> For testing I used classlib (trunk) compiled
with ECJ 3.3 with
>>>>>>> -source
>>>>>>>>>>> 1.6 -target 1.6 and all VM acceptance tests compiled
with Sun's
>>> javac
>>>>>>>>>>> from JDK 6.0.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Gregory
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Gregory
>>>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>> Gregory
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Gregory
>>>>>
>>>>>
>>> --
>>> Gregory
>>>
>>>
> 


-- 
Gregory


Mime
View raw message