[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]