harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm] DRLVM should accept Java6 classes now
Date Thu, 06 Sep 2007 17:06:21 GMT
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.

Regards,
Tim

> 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
>>
>>
> 

Mime
View raw message