harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] DRLVM should accept Java6 classes now
Date Thu, 20 Sep 2007 13:00:41 GMT
Do we need to make virtual machine backward compatible with previous
versions of class library?
Or what we are really trying to solve is "initial support of java6 - namely
java6 class file version - in DRLVM without branching"?


On 9/18/07, Tim Ellison <t.p.ellison@gmail.com> 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.
> Regards,
> Tim

Pavel Pervov,
Intel Enterprise Solutions Software Division

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message