[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Java policy change proposal: runtime/compiler selection


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 van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)

Reply to: