Leo Li wrote:
On 10/13/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
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.
Ya, "java -version" need not be so fast. And the version really is
related to classlib. I am to some degree too mad about performance:)
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.
Is the plan all right?
Yes, that was the plan :)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
