On 10/13/06, Geir Magnusson Jr. <geir@pobox.com> 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?
>
> --
> Leo Li
> China Software Development Lab, IBM
|