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 gshimansky@gmail.com
 designates 64.233.162.237 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:content-type:content-transfer-encoding;
        b=pzho8eVTLq56PclS5Gm3aw/Tfypt+HYgqRRnZm4m1kQC31jCsVYscrkyOucaYsV/kUkg8FYLA4UWNzd8LttrfClOZRqq75ntBr+KrlGyuwg/eIWIja3M7Blz6rC1khuVmntqTYo6YrhcBldFUk3nFod7ZCvLJGbAZLHfFuq+8Iw=
Message-ID: <46EFCC7E.8010608@gmail.com>
Date: Tue, 18 Sep 2007 17:02:54 +0400
From: Gregory Shimansky <gshimansky@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>
 <46E0338D.30105@gmail.com> <46E11C7A.9050102@gmail.com>
 <46E1343E.2010305@gmail.com> <46EFA4AE.70604@gmail.com>
In-Reply-To: <46EFA4AE.70604@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tim Ellison wrote:
> Sorry for the delay in responding...
> 
> Gregory Shimansky wrote:
>> Gregory Shimansky wrote:
>>> 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.
>> Hmm now that I think of it there may be a recursion. To get a value of
>> java.class.version VM would need to load at least some classes from
>> classlib which would require knowing the supported class version of VM
>> side. But this property could be supplied by the launcher from the VM
>> command line.
>>
>> Launcher is still a part of classlib so there may be different version
>> of for Java5 and Java6.
> 
> I wasn't thinking of running any java code to supply it, but how early
> do you need to know?  Is it too late after create java vm?  How about we
> notify you in the class library JNI_OnLoad for LUNI, i.e. call into the
> VM and set the java.class.version using the VMI functions.
> 
> I'm reluctant to add extra login in the launcher since the VM should
> work equivalently when embedded in anyone's program.

This could work well if JNI_OnLoad for LUNI works before any Java code 
is loaded. I think it works this way currently because when bootstrap 
class loader initializes it loads bootstrap native libraries, LUNI first 
of all.

I think it is the best solution!

-- 
Gregory