2009/3/19 Oliver Deakin <[email protected]> > 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. > > 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 > >
