Linux Archive

Linux Archive (
-   Debian Development (
-   -   Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine (

Niels Thykier 04-19-2010 06:33 PM

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine
Package: debian-policy
Severity: wishlist
Justification: Policy §3.6

Hash: SHA1


As of today[1], the Java Policy retired the use of the virtual packages mentioned
in the subject line, which brings the Java Policy closer to the actual practices
used by the Java Team.

The replacement guide for the packages are as described below. Please note that
these are guide lines for the average case. If a package does not fit "in",
feel free to contact the Java Team (debian-java@l.d.o) about it.

- none if already depending(or recommending/...) on a java runtime[2].
- An alternative list of java runtimes (see [2]) otherwise.

- default-jdk. If used in an alternative in Build-Depends{,-Indep} then pick
one of the options (The Java Team recommends default-jdk).

In case you change your Build-Depends{,-Indep} to include default-jdk, you
should update JAVA_HOME to /usr/lib/jvm/default-java if your build system
(e.g. ant) uses it.

Please do *not* switch to default-jdk-builddep without consulting the Java Team
first. On most architectures default-jdk-builddep will pull *two* full Java
Development Environments.
There is a reason for "insanity"; if you are interested then get in contact with
the Java Team.

Thank you in advance,

NB: I am subscribed to debian-devel@l.d.o, but not debian-policy@l.d.o; please CC
me accordingly.


[2] e.g. one of these default-jre, default-jre-headless, java1-runtime, java2-runtime
If you use indiviual JVMs (e.g. gij or gcj) it may be worth replacing them with
default-jre{,-headless} plus alternatives.
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkvMoaIACgkQVCqoiq1YlqyQkwCfSvVWBsnto4 SlIeGuitjsOIBd

Niels Thykier 11-29-2011 05:52 PM

Bug#578421: virtual-packages: Retire java-compiler, java2-compiler and java-virtual-machine
On 2011-11-29 00:32, Bill Allombert wrote:
> On Wed, Apr 21, 2010 at 11:07:53AM +0200, Niels Thykier wrote:
>> Rene Engelhard wrote:
>>> On Mon, Apr 19, 2010 at 08:33:12PM +0200, Niels Thykier wrote:
>>>> [java{,2}-compiler]
>>>> - default-jdk. If used in an alternative in Build-Depends{,-Indep} then pick
>>>> one of the options (The Java Team recommends default-jdk).
>>> And what are you going to do as replacement for "whatever Java compiler, I don't care
>>> as long as it understands Java 2"?
>>> Grüße/Regards,
>>> René
>> Hi
>> Good point.
>> A java compiler is usually useless without the a backing Java core
>> library, so you probably want to replace it with a JDK.
>> Also please note that we have removed a lot of JVMs from Squeeze;
>> currently Debian has 3 or so left.
>> * openjdk-6
>> * gcj/gij
>> * sun-java6 (non-free)
>> * default (which is either openjdk-6 or gcj/gij)
>> As I recall there is also a JVM implemented in .NET or so, but it does
>> not identify itself via one of the javaX-runtime (nor the java-compiler
>> ones) and I cannot remember its name offhand.
>> Aside from the mono JVM (which I do not really know), all of them can
>> run Java5 code[1], so basically it is useless to have both java-compiler
>> and java2-compiler.
>> On a related note: it appears that only sun-java6 provides
>> java2-compiler (even though all others could provide it as well).
>> If I was to replace a java{,2}-compiler to mean "Any java compiler" I
>> would use:
>> default-jdk | gcj-jdk | sun-java6-jdk [3]
>> But I would definitely consider only using default-jdk (especially for
>> Suggests). While that may seem a bit strange as replacement for "Any
>> compiler" consider the following:
>> default-jdk is either openjdk-6-jdk or gcj-jdk
>> openjdk-6 is based on the same source as sun-java6
>> openjdk-6 is available any architecture where sun-java6 is.
>> gcj-jdk is inferior to openjdk-6 (not only due to [1])
>> While sun-java6 is still superior to openjdk-6 in some cases, I believe
>> this is only a runtime thing and not a compile issue. So by using
>> default-jdk you get the best compiler we got and it is shorter.
>> Of course there are users using sun-java6-jdk which will not like if
>> apt pulls in a second JDK, so for Recommends+Depends it may be worth to
>> use the alternatives.
>> With a little grep-dctrl magic I noticed we 1 absolute dependency on
>> javaX-compiler (laby), four Recommends (robocode, jde, jython, mmake)
>> and 5 Suggests (ant, ant1.7, cup,, lab).
>> There are also 6 Build-Depends(-Indep) cases, but I already covered
>> those. All in all we got a total of 15 (9 + 6) uses of java-compiler and
>> java2-compiler, so they do not appear to be widely used.
>> ~Niels
>> [1] gcj/gij does not implement the full Java5 API.
>> [2] Should be updated, since gcj is a transitional package.
>> [3] You could add openjdk-6-jdk to this list, but on architectures where
>> openjdk-6 is available, it will be pulled by default-jdk.
> Hello Renee,
> Are you fine with that change ?
> Niels, can you get other Java people to second this ?
> Cheers,


Considering the retirement of these virtual packages was up for public
debate on d-java in 2010[1], it shouldn't be a problem to get someone to
(re-)second this. :)

So, hallo d-java people - if you (still) agree with this change, please
reply to #578421. :)



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

All times are GMT. The time now is 07:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.