Java policy change proposal: runtime/compiler selection
Hi,
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.
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.
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
- 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
- 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.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: