harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: about java -version issue for harmony java launcher
Date Thu, 19 Mar 2009 10:33:31 GMT
Deven You wrote:
> 2009/3/19 Oliver Deakin <oliver.deakin@googlemail.com>
>> That sounds similar to the solution I was thinking of as well - we could
>> create an internal Harmony class that looks up properties/version values and
>> constructs an output version information string from them. This class would
>> be invoked by the launcher if the -version option is found anywhere in the
>> command line options.
>> I see that J9 puts it's full version information in the java.fullversion
>> and java.vm.info properties, but these are non-standard. I cannot see the
>> version info that drlvm prints when passed -version in any Java property.
>> The standard Java properties only provide high level version information
>> (not full component breakdown, build dates, repository revision etc.).
>> Perhaps drlvm could also set the java.fullversion (or some other) property -
>> then the class that puts together the version information could look at this
>> property first and if it exists use it, otherwise fall back to the standard,
>> less detailed, properties (java.vm.version, java.vm.name etc.).
>> For the class libraries, I agree that a per module version info might be
>> quite useful - I guess we would want to output the Bundle-Name and
>> Bundle-Version from each jar manifest?
>> Regards,
>> Oliver
>> I agree this opinion and I suggest may we use another option like
> -classlibversion to show the classlib version information.

It's a good idea, -version should show brief information about classlib, 
like svn revision, build time, -classlibversion show all detail 
informations of each modules. It could be a Harmony extension :)

>> Tim Ellison wrote:
>>> Deven You wrote:
>>>>  Harmony java launcher  "java -version" command can not work with IBM J9
>>>> VM26 . The error result is as below:
>>>>  ../jres/see/bin/java -version
>>>> Apache Harmony Launcher : (c) Copyright 1991, 2008 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
>>>> This issue occurs on both linux and windows x86 platform.
>>>>  I find our laucher just invoke the mothod JNI_CreateJavaVM()  of  vm
>>>> which
>>>> on j9 vm does not deal with -version option according to JNI
>>>> Specification.
>>>> the specification says:
>>>> "All Java virtual machine implementations must recognize the following
>>>> set
>>>> of standard options:  ..."
>>>> it lists:
>>>>  -D<name><value>
>>>>  -verbose
>>>>  vfprintf
>>>>  exit
>>>>  abort
>>>> It then goes on to stay:
>>>> "In addition, virtual machine implementations may support their own set
>>>> of
>>>> implementation-dependent option strings.  Implementation-dependent option
>>>> strings must begin with "-X" or an underscore."
>>>> Any other option is non-standard.
>>>> but for DRLVM, seems its JNI_CreateJavaVM() does not comply with JNI
>>>> Specification and support -version option.the result is below:
>>>> Apache Harmony Launcher : (c) Copyright 1991, 2008 The Apache Software
>>>> Foundation or its licensors, as applicable.
>>>> java version "1.5.0"
>>>> pre-alpha : not complete or compatible
>>>> svn = r745401, (Feb 18 2009), Windows/ia32/msvc 1310, release build
>>>> http://harmony.apache.org.
>>>> but there is still no vm version info.
>>>> I suggest our java launcher should not pass -version or other
>>>> non-standarad
>>>> options  to vm interface JNI_CreateJavaVM(), instead we should make a
>>>> general solution to deal with them, maybe call certain methods in jre
>>>> tool
>>>> package. so that  our java laucher can work well on different vms.
>>> Sounds reasonable to me.
>>> A basic implementation would create the VM then query the values in
>>> java.vm.version etc and print those, a more sophisticated (and longer
>>> running<g>) implementation would run a Java class and pull out the VM
>>> version plus version information from our class library JARs too.
>>> (We would need to define the SVN build info as a property too so it can
>>> be picked up from Java)
>>> Regards,
>>> Tim
>> --
>> Oliver Deakin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>> PO6 3AU

Best Regards,

View raw message