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 [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
