On Dec 1, 2010, at 12:56 PM, Ulf Zibis wrote:
Am 01.12.2010 20:38, schrieb Kelly O'Hair:
On Dec 1, 2010, at 11:15 AM, Ulf Zibis wrote:
Am 01.12.2010 17:43, schrieb Kelly O'Hair:
4.) "properties" file vs command line option or dll usage
interface:
- the interpretation of the usage/options.txt files should be
optional for a launcher, but not
guaranteed to work.
- I propose additional command line options to output the valid
choices
(=content of the maybe existent hidden options.txt file) as java
-X does today:
-- just execute: java -options -Xoptions -XXoptions -
version:minOS -version:java -version:lib
-version:vm (including the build)
-- in case of multiple VMs: java -Jrocket -XXoptions or -
XXoptions:Jrocket
-- to test a single option or any combination, execute: java -? -
XXMaxPermSize[=64] and return 0
| 1 | -1
or better: java -n[othing] -XXMaxPermSize[=64] for do nothing,
just check the syntax.
- for the dll there should be a well defined interface/api to
retrieve the version + options values.
- using command line options or dll api for that purpose is
common practice for many other
applications, at least in Windows.
I'm completely lost here, what does the above have to do with my
jdk.release proposal?
Seems like you are talking about a completely different thing.
If I understand correct, your proposal should "make life easier"
for application launcher developers.
Isn't it easier to just run "java -options" etc. instead of
maintaining the names of "jdk.release", "jre.release" + opening a
file + parsing the java properties syntax + again opening another
"jvm.cfg" file + parsing a different syntax + matching the
retrieved information with potential valid to be maintained option
strings ?
'java -options' would launch a VM, I'm trying to avoid that.
The java executable will be executed anyway by Eclipse launcher, at
least on *nix (and probably on Mac):
"On *nix, in case (1) we exec "java -version" and look for the
string "Java HotSpot(TM)" or "OpenJDK" in the result."
But I wonder, if "java -version" or "java -options" would launch the
VM, if there is no java class to be executed
Yes, 'java -version' launches a VM, and loads up many shared libraries.
If some tool vendors can do that, then they
could write a small java class file that does exactly what they
want and run that.
In this case, the VM indeed must be launched, and twice, for the
version/options info to be retrieved, and later for the real
application.
That's what using java -version does, you have launched the VM twice.
It's the same thing.
You might be avoiding some class file loads with java -version, and it
is probably quicker, but the
native VM library is loaded and run when you do a 'java -version'.
Besides the minor performance hit, in my situation maybe someone
installed or copied over the wrong jdk, say a Linux jdk image
onto a Solaris machine, the java command will fail in some strange
way.
The same problem you would have, if you had copied a wrong firefox
image onto a Solaris machine and click on a web link in a document
or your email client, the referring to firefox will fail in some
strange way.
IMO such situations should not be managed by the jdk image itself,
but from the installer, which should verify the correct machine.
Sometimes formal installers are not available, and as we move forward
into the cross-compiler build world,
even the installers might not be able to help you if you install a
Linux PPC image on a Linux X86 system
so that you can do comparisons or partial cross compilation builds for
PPC. Or the installer will block you
and then you are back to raw install image copies.
The installer is a great place for these checks but a formally
installed image is not always available.
And sometimes via NFS access, the files might not even belong to the
system you are running on.
I'd like to know what kind of jdk image I have before I start it up.
Dito for having a x86_64 jdk image and running it on a 32bit OS.
Dito installer problem.
Or maybe my launcher is smart enough to know that a jdk1.7.0
version will not work on the system and wants to
avoid even trying to starting it up, using a jdk1.6.0 image instead.
Dito launcher's installer problem.
I am more after something like the /etc/*release files on a Solaris
or Linux system.
But yes, those scenarios could be improved, but IMHO smarter with
something like "java -version:java", (or interpreting the existing
"java -version" output, like Eclipse does), ... and - more important
- would it solve the original problem, i.e. checking if some exotic
option is available.
And think about future changes about another exotic parameters.
Would vm.name=hotspot + jdk.java.version=1.7.0 be enough to serve
this?
If my application wants to zip something, should it look for some
"zip.release" file to estimate, if some rare option, let's say
deflate64 compression, would be available. No, it should find the
info in the zip.exe or zip.dll file, by some standardized api or by
using GetFileVersionInfo on Windows.
And last ... should we have a "jdk.javac.release" file too some day?
I'm obviously not communicating very well.
I don't want to run 'java' because I might not be able to, and I don't
want to use some platform specific api
to dig into binaries that may be located at any number of locations.
I'm looking for a very simple text file way to identify what I kind of
jdk image I have.
There are numerous ways to determine this as you point out, but none
that remove the native binary execution,
or grokking around inside binary files.
-kto
-Ulf
