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. Regards, Tim > 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 >> >> >
