[snip]
> > What are you concerned about wasting? It will take longer for sure, but > > 'java -version' doesn't need to be super fast (it prints to the console > > and quits). In addition, we should consider gathering version > > information from the class library code too, i.e. to show each module > > version. I don't think it warrants extending the VMI.
I suppose modules={vm, classlib} here? That is quite reasonable; there are specific properties documented in API docs: "java.version" Java Runtime Environment version "java.vm.version" Java Virtual Machine implementation version RI additionally provides undocumented "java.runtime.version", with value usually equal to java.vm.version
[snip]
If we have decided not to transfer version as an option into vm, we can make some change in launcher: 1.When create vm, "-version" is not included as part of vm argument, thus our vm will not report error. 2.When vm created, we uses a JNI call to System.getProperty("java.version") or VMI funciton GetSystemProperty("java.version")to show it to user. I am not sure which way is better.
VMI is preferable - with the same functionality, it is still faster :) -- Alexey --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]