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 Tue, 18 Sep 2007 10:13:02 GMT
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.


View raw message