Java policy change proposal: runtime/compiler selection
  Home FAQ Contact Sign in
linux.debian.maint.java only
 
Advanced search
POPULAR GROUPS

more...

linux.debian.maint.java Profile…
 Up
Java policy change proposal: runtime/compiler selection         


Author: Jeroen van Wolffelaar
Date: Aug 19, 2006 09:00

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...
Show full article (2.93Kb)
4 Comments
Re: Java policy change proposal: runtime/compiler selection         


Author: Matthias Klose
Date: Aug 19, 2006 10:30

Jeroen van Wolffelaar writes:
> and how to set priorities is unclear and not easy to decide on.

IIRC that we decided on the priorities. See
http://lists.debian.org/debian-java/2006/05/threads.html
> 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.

Do you want to include every jar in a "generic" classpath?
> 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.

Your proposal only addresses runtime environments, not build
dependencies, and how they should configured. We discussed that in
Oldenburg (you included). You may want as well look at FC how the
classpath is configured for specific applications.
Show full article (1.46Kb)
no comments
Re: Java policy change proposal: runtime/compiler selection         


Author: Tom Marble
Date: Aug 21, 2006 13:50

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
Show full article (6.80Kb)
2 Comments
Re: Java policy change proposal: runtime/compiler selection         


Author: Matthias Klose
Date: Aug 23, 2006 02:00

Tom Marble writes:
> 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.

we currently do have this problem; maybe the introduction of a
null-environment with dummy binaries would avoid that.
>> 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...
Show full article (3.09Kb)
1 Comment
Re: Java policy change proposal: runtime/compiler selection         


Author: Tom Marble
Date: Aug 23, 2006 14:30

Matthias Klose wrote:
> Tom Marble writes:
>> 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.
>
> we currently do have this problem; maybe the introduction of a
> null-environment with dummy binaries would avoid that.

That sounds like a good idea.
Should we also add a comment to all JVM post-inst's that selecting
this (or any) Java implementation can be done with UJA?
Show full article (4.85Kb)
no comments