On the 0x34A day of Apache Harmony 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.
+1 > >> On 9/6/07, Gregory Shimansky <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >>> > >>> > > > > > -- > Gregory > > -- Egor Pasko
