Tim Ellison wrote:
Sorry for the delay in responding...
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.
I wasn't thinking of running any java code to supply it, but how early
do you need to know? Is it too late after create java vm? How about we
notify you in the class library JNI_OnLoad for LUNI, i.e. call into the
VM and set the java.class.version using the VMI functions.
I'm reluctant to add extra login in the launcher since the VM should
work equivalently when embedded in anyone's program.
This could work well if JNI_OnLoad for LUNI works before any Java code
is loaded. I think it works this way currently because when bootstrap
class loader initializes it loads bootstrap native libraries, LUNI first
of all.
I think it is the best solution!
--
Gregory
