Tim Ellison wrote:
Leo Li wrote:
Due to current VMI, we have to first create a java VM through
JNI_CreateJavaVM, then we can get property from functions defined by
VMI. It is possible not to change current vmi design and support java
-version, but
we have to create and then "kill" a new java vm. So I think it quite
wastes. I suggest the vmi.dll export another funciton to give out
some "static" property of the java vm implementation that is no
relevent to a live vm.
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.
Yes - as Tim noted, we probably don't care if typing "java -version" is
slow (unless some bonehead puts that into a SPEC benchmark...) because
the user isn't trying to accomplish anything useful.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
