Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=tSereK7pyiOap9LYb211YfcM2P9W/Dc+/bpjDURqYAt/hH8SAZLV5mqJ2ZlOhNGqwFQQPxcUDz12rNAwFcNYaF8UW51W58Ah2OJvleBZc1k+y9F7B4cr2qRO75HYIu0iJ7ve2iBc//nu2x79sAMk5xLwXS7tjEvq8hrg31S8Eg8=
Message-ID: <46E0338D.30105@gmail.com>
Date: Thu, 06 Sep 2007 18:06:21 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [drlvm] DRLVM should accept Java6 classes now
References: <46DD72E3.9060108@gmail.com>
	 <6e47b64f0709042159r39240301m220ac43c992599be@mail.gmail.com>
	 <46DE8E11.3060909@gmail.com>
	 <fb98610c0709060222k7ed88e71p93bdd5d459c5493c@mail.gmail.com>
	 <46DFEC63.7020709@gmail.com>
	 <fb98610c0709060541l1dc041c7r2be50827a785e77@mail.gmail.com>
	 <46DFFB6F.1050909@gmail.com>
 <0vqvean3npr.fsf@gmail.com>	 <46E007A0.3030609@gmail.com>
 <fb98610c0709060901x2494b4a8rce3e4f9f715dfb52@mail.gmail.com>
In-Reply-To: <fb98610c0709060901x2494b4a8rce3e4f9f715dfb52@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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