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.
--
Gregory
