> we can make this constant definable by the build. That's a great idea. I agree.
Thanks, Yuri 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 > >
