You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tony Wu <wu...@gmail.com> on 2006/10/11 13:14:25 UTC
[classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
I encounter an error[1] when run java -version with IBM VME today and
it is ok on DRLVM. I wonder how to handle these simple parameters. Is
there any decision
about that?
[1]
qbit@qbit-ibm:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java -version
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
JVMJ9VM007E Command-line option unrecognised: -version
HMYEXEL062E Internal VM error: Failed to create Java VM
FAILED to invoke JVM.
--
Tony Wu
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Posted by Vladimir Ivanov <iv...@gmail.com>.
This issue was discussed several times already. Seems that the set of
'standard' options should be defined for Harmony VM's and describe
somewhere.
But nobody do it yet :)
thanks, Vladimir
On 10/11/06, Tony Wu <wu...@gmail.com> wrote:
>
> I encounter an error[1] when run java -version with IBM VME today and
> it is ok on DRLVM. I wonder how to handle these simple parameters. Is
> there any decision
> about that?
>
> [1]
> qbit@qbit-ibm:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java
> -version
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
> Foundation or its licensors, as applicable.
> JVMJ9VM007E Command-line option unrecognised: -version
> HMYEXEL062E Internal VM error: Failed to create Java VM
> FAILED to invoke JVM.
>
> --
> Tony Wu
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib][launcher]shall we handle the parameter -version and
-showversion in launcher or vm?
Posted by Tim Ellison <t....@gmail.com>.
Alexey Varlamov wrote:
> [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
Right, so I would expect the launcher to print out a reasonable summary
of the VM and class library version information. We will particularly
require both (VM & classlib) in Harmony because it is so easy to run
with different VMs.
he brief version info may be the spec version number (1.5) and the svn
build info from classlib, plus whatever the VM chooses to report.
We might also consider a -version:verbose or whatever which prints out
the version info from each module in classlib. That will help show
which version of, say Yoko or Logging is being used. We can write a
simple class in Java to print that for us.
> [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 :)
I don't care about it being fast.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Posted by Alexey Varlamov <al...@gmail.com>.
[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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Posted by Tony Wu <wu...@gmail.com>.
hi all,
please do not forget there is a *-showversion* which prints version
and continues ;-)
On 10/13/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Leo Li wrote:
> > On 10/13/06, Geir Magnusson Jr. <ge...@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?
>
> Yes, that was the plan :)
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tony Wu
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and
-showversion in launcher or vm?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Leo Li wrote:
> On 10/13/06, Geir Magnusson Jr. <ge...@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?
Yes, that was the plan :)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Posted by Leo Li <li...@gmail.com>.
On 10/13/06, Geir Magnusson Jr. <ge...@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
Re: [classlib][launcher]shall we handle the parameter -version and
-showversion in launcher or vm?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and
-showversion in launcher or vm?
Posted by Tim Ellison <t....@gmail.com>.
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.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib][launcher]shall we handle the parameter -version and -showversion in launcher or vm?
Posted by Leo Li <li...@gmail.com>.
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.
On 10/12/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Tony Wu wrote:
> > I encounter an error[1] when run java -version with IBM VME today and
> > it is ok on DRLVM. I wonder how to handle these simple parameters. Is
> > there any decision
> > about that?
> >
> > [1]
> > qbit@qbit-ibm:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java
> -version
> > Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
> > Foundation or its licensors, as applicable.
> > JVMJ9VM007E Command-line option unrecognised: -version
> > HMYEXEL062E Internal VM error: Failed to create Java VM
> > FAILED to invoke JVM.
> >
>
> Yes, we won't pass -version into the VM, but simply have an expectation
> that the VM will set a property that can be read by the launcher post VM
> init.
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][launcher]shall we handle the parameter -version and
-showversion in launcher or vm?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tony Wu wrote:
> I encounter an error[1] when run java -version with IBM VME today and
> it is ok on DRLVM. I wonder how to handle these simple parameters. Is
> there any decision
> about that?
>
> [1]
> qbit@qbit-ibm:~/harmony/workspace/trunk/deploy/jdk/jre/bin$ ./java -version
> Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
> Foundation or its licensors, as applicable.
> JVMJ9VM007E Command-line option unrecognised: -version
> HMYEXEL062E Internal VM error: Failed to create Java VM
> FAILED to invoke JVM.
>
Yes, we won't pass -version into the VM, but simply have an expectation
that the VM will set a property that can be read by the launcher post VM
init.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org