On Dec 1, 2010, at 7:27 AM, Ulf Zibis wrote:
1.) naming:
a: What would be the name for the JRE installation, "jre.release" ?
That would be a separate RFE in my opinion, easy to do but my primary
target was the jdk for now.
b: As we have a bin\client\Xusage.txt, we additionally could have:
- bin\usage.txt
- bin\client\XXusage.txt
- bin\Jrocket\XXusage.txt
- etc.
and maybe (without help text, but with well defined syntax):
- bin\options.txt
- bin\client\Xoptions.txt
- bin\client\XXoptions.txt
- etc.
or specify the syntax of the left column of the *usage.txt files.
The bin directory would be a good location, as it is well known for
the java.exe.
I have been trying to limit the scope of this as much as possible,
this seems to be making it much
more complicated than I want or I think anyone needs.
2.) jre/lib/xxx/jvm.cfg:
- the naming "cfg" is confusing. It is normaly used for user
configurable settings, but there is nothing to configure.
- e.g. netbeans/etc/netbeans.conf
It's a older historic name, I did not pick it. It is up to the VM
teams to change.
3.) Don't use java properties syntax:
- the launcher, here Eclipse, should know/maintain the valid
matching from the properties to the available options.
- so make it quite simple: just list the real options + valid values
in their original spelling
How much more simple can you get name=value? Very platform neutral.
And what are these "real options" and "original spellings"? Can you
clarify?
- could not be mixed with java runtime properties
Why not? If the names do not overlap, don't start with "os." or
"java.", what is the harm?
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
- 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.
5.) Windows DLL/EXE COMPANY value:
- we should use the valid "Oracle"
- applications, which rely on this, should be updated, as well, as
they should, if there is a new java version/build with new/dropped
options
Actually "Oracle Corporation", but again, not sure what this has to do
with the jdk.release proposal now that
I have removed the vendor values from it.
I do agree about COMPANY, just haven't felt like we had much choice in
the matter. :^(
However, the default OpenJDK build (from the top) will probably only
say "Oracle Corporation" on the java
specification vendor properties.
I'm pretty sure that windows COMPANY value, java.vendor and
java.vm.vendor will default to "N/A" or
whatever the make variable COMPANY_NAME says. Or if the build is done
with an explicit 'make OPENJDK=true'.
The top Makefile will make an early check to see if OPENJDK should be
set to true, not sure about all Makefiles.
-kto
My cents ...
-Ulf
Am 01.12.2010 02:34, schrieb Kelly O'Hair:
A revised proposal...
Still called "jdk.release".
But if people really think "jdk.properties" sounds ok, at least the
names are unique and won't conflict.
http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release2/webrev/
A Linux 64bit build should result in a jdk.release file that looks
something like:
jdk.os.name = Linux
jdk.os.version = 2.6
jdk.os.arch = amd64
jdk.java.version = 1.7.0
jdk.vm.cfg.files = jre/lib/amd64/jvm.cfg
-kto
