On the 0x34A day of Apache Harmony 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.
yep, I thought about it too, but that should be easy to compile a bunch of classes necessary to get this option in a special mode that is java5 and is compatible with java6. To my memory, we should disable jsr/ret instructions. Anything else? -- Egor Pasko
