Re: Java policy change proposal: runtime/compiler selection
Jeroen van Wolffelaar wrote:
> Currently, there is update-java-alternatives in java-common to manage
> the various java commands and how they refer to which implementation.
> People can however ignore it and update-alternatives themselves, things
> can get out-of-sync, and how to set priorities is unclear and not easy
> to decide on.
problem 1: update-alternatives w/o update-java-alternatives (UJA) can
lead to an "out of sync" situation.
> In the current Debian Java policy, java libraries are required to
> properly document how to modify classpath such that people can use them
> -- this does not work automatically.
problem 2: setting classpath does not happen automatically
> Because of the above two issues, let me propose a different approach.
>
> - All java commands such as /usr/bin/java, javac, javap, javadoc, etc
> etc are all replaced by a shellscript provided by java-common. The
> alternatives are removed
Regrettably I must state that this would break a very large number
of things.... the reason is that the PID returned by the /usr/bin/java
script would be for the script and not Java. We found out in the course
of developing JDK 6 that when we introduced a feature (called the
mini-launcher) that this problem of having the PID returned *not* be
that of the target JVM process caused a great deal of problems related
to job control of Java applications.
We even imagined scenarios of having the mini-launcher continue to
live and subrogate process control to <-> from the target Java process,
but, alas, that became infeasible as well when various forms of signal
handling and race conditions were evaluated.
> - There is one 'register' directory managed by java-common where any
> application providing: a (1) JVM, (2) java compiler, (3) java runtime
> libraries (4) java to-native compiler, to add a file to indicate they
> provide it, along with a priority much like the alternatives priority
> - java-common provides a command to actually select a combination of
> implementations for each area. This would also be the place to prevent
> illegal combinations. Preferences are stored somewhere in /var/lib,
> 'automatic' being one possible (and the default) configuration
problem 3: illegal combinations are avoided
(this is similar, but different from problem 2)
> - When a user invokes for example /usr/bin/java, the shellscript
> consults the register directory, and retrieves the currently selected
> implementation. It initializes environment variables as needed, and
> execs the correct implementation.
> - Notably, classpath is properly initialized to include all properly
> packaged and installed java libraries, so that after an apt-get
> install libgnu-regexp-java (for example), invoking 'java' and 'javac'
> will actually by default simply find it (similar to 'ldconfig').
> Certain providers of runtime and compiler can request this not to
> happen automatically (such as Sun's) in case that would via a
> violation of that implementation's license (either whitelist of
> blacklist-based). This way, a java.awt implementation can exist and
> work out-of-the-box for kaffe, while the system will be configured to
> not use that library when Sun's 'java' is invoked
>
> If this (rough) proposal meets with appreciation, I could make it more
> concrete and provide a java-common implementing this policy. Any
> comments welcome. Also pointers to any prior discussion about solutions
> wanting to address the same problems, I realize that I did not do very
> much research to prior proposals and discussion on the matter, for which
> I aplogize. I didn't want to delay this mail until I'd find time to do
> such research, and this idea wasn't as 'current' anymore.
so, in order to address the problems above:
proposed solution to problem 1:
Would it be possible to use slaves or some other mechanism of
update-alternatives to avoid this scenario? I expect this use case --
of needing to marshal more than one alternative at the same time --
may not be limited to Java. One way would be to extend update-alternatives
with the concept of a "group hook"? The idea would be that modifying the
alternative without using the group hook would result in a "are you sure?"
message.
The problem with this solution is that it would require a fundamentally
new behavior in update-alternatives which, as it's end result, simply protects
the user from naive behavior. Instead of a technical solution, could
we address this problem through better documentation?
proposed solution to problem 2:
It seems that section "2.3 Java Programs" in http://wiki.debian.org/Java/Draft
suggests that java programs should have a shell script in /usr/bin
as a launcher. So, presumably, the canonical form of a (non-daemon) java
program "foo" is a shell script in /usr/bin/foo like this:
#!/bin/sh
# launcher for foo
# here's one example of launching with a specific classpath
classpath="-cp /usr/share/java/foo/foo.jar:/usr/lib/java/bar.jar"
# here's an example of launching a jar with the main class in the manifest
# classpath="-jar /usr/lib/jvm/java-1.5.0-sun/demo/jfc/Java2D/Java2Demo.jar"
compiler="-server" # for example
heap="-XX:NewSize=56m -XX:MaxNewSize=56m -Xms512m -Xmx512m" # example initial heap settings
gc="-XX:+UseParallelGC -XX:+UseParallelOldGC" # example gc settings
misc="-XX:+PrintGCDetails" # example misc tunables
jvmargs="$classpath $compiler $heap $gc $misc"
appargs="foo.MainClass $*" # for example, pass args from the user to the application
args="$jvmargs $args"
# assume /usr/bin/java has been set by update-java-alternatives
exec java $jvmargs $args
proposed solution to problem 3:
The only example of inappropriate combination that we have found to date
was very obviously using Sun's rt.jar to complete (mix and match) an
alternative technology. I suspect that the Debian Java Maintainers will
immediately notice such mix-and-match scenarios when evaluating the
proposed Java application launch scripts. I'm concerned that a whitelist
or even blacklist approach would be far too burdensome to maintain.
Java application maintainers which follow Debian Java Policy of making their
packages runtime independent should not run into any troubles anyway.
Therefore IMHO solutions to problems 1 and 2 should be sufficient to
address the concern from problem 3.
Regards,
--Tom
_____________________________________________________________________________
Tom.Marble@sun.com (952) 832-4123
Senior Java Performance Engineer Sun Microsystems, Inc.
http://blogs.sun.com/tmarble What do you want from Java Libre?
Reply to: