Inconsistent 'Provides' for different java compilers/runtimes

Bug #189953 reported by Onkar Shinde on 2008-02-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
icedtea-java7 (Ubuntu)
Matthias Klose
openjdk-6 (Ubuntu)

Bug Description

Following are values for 'Provides' field for different java compilers/runtimes.

icedtea-java7-jdk - java-sdk, java2-sdk, java5-sdk, java6-sdk, java7-sdk
icedtea-java7-jre - java-runtime, java2-runtime, java5-runtime, java6-runtime, java7-runtime
sun-java5-jdk - java-compiler, java2-compiler
sun-java5-jre - java-runtime, java-runtime-headless, java2-runtime, java2-runtime-headless, java5-runtime, java5-runtime-headless, java-virtual-machine
sun-java6-jdk - java-compiler, java2-compiler
sun-java6-jre - java-runtime, java-runtime-headless, java2-runtime, java2-runtime-headless, java5-runtime, java5-runtime-headless, java6-runtime, java6-runtime-headless, java-virtual-machine
gcj-4.2 - java-compiler
gij-4.2 - java-runtime-headless, java1-runtime-headless, java2-runtime-headless, java5-runtime-headless, java-virtual-machine
kaffe - Doesn't have a 'Provides' field
jikes - Doesn't have a 'Provides' field
sablevm - java-runtime, java1-runtime, java-virtual-machine

As per my understanding
java-compiler - just a compiler without a VM ex. jikes
java-virtual-machine - just a VM without a compiler ex. sablevm
java-runtime - compiler + VM.

Irrespective of whether my understanding is correct or not there has to be a consistency. Specifically icedtea-java7-jdk is out of sync with other compilers like Sun, GCJ.

Daniel Hahler (blueyed) wrote :

icedtea-java7-jre should provide java-virtual-machine, so that it can satisfy the dependencies of e.g. ant:
java-gcj-compat-dev | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime, libxerces2-java

Changed in icedtea-java7:
importance: Undecided → Wishlist
status: New → Triaged
Daniel Hahler (blueyed) wrote :

Matthias, please consider using the attached patch or ACK that I should upload it. Thank you.

icedtea-java7 (7~b24-1.5+20080118-2) hardy; urgency=low

  * debian/control: Fix provides for -jdk and jre (LP: #154374)
    - icedtea-java7-jdk additional provides java-compiler, java2-compiler
    - icedtea-java7-jre additional provides java-virtual-machine
  * debian/ fix update-java-alternatives examples

 -- Daniel Hahler <email address hidden> Wed, 13 Feb 2008 19:17:01 +0100

Matthias Klose (doko) wrote :

already done in the vcs.

Changed in icedtea-java7:
status: Triaged → In Progress
Daniel Hahler (blueyed) wrote :

Do you mean ?
Will this make it into Hardy?

Changed in icedtea-java7:
assignee: nobody → doko
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openjdk-6 - 6b06-0ubuntu12

openjdk-6 (6b06-0ubuntu12) hardy; urgency=low

  * Update icon locations in menu files.
  * openjdk-6-jre-headless: Provide java-virtual-machine. LP: #189953.
  * openjdk-6-jre-headless: Add a conflict to gcjwebplugin; for openjdk
    use the icetea-gcjwebplugin, for gij the java-gcj-compat-plugin.

 -- Matthias Klose <email address hidden> Sat, 22 Mar 2008 20:12:41 +0100

Changed in openjdk-6:
status: New → Fix Released
Matthias Klose (doko) wrote :

icedtea-java7 is now removed from hardy

Changed in icedtea-java7:
status: In Progress → Invalid
Claes Wallin (clacke) wrote :

This is still a problem in openjdk-6 6b18~pre1-1ubuntu1. Installing default-jdk-builddep forces a gcj install even though openjdk-6-jdk is already installed.

Onkar Shinde (onkarshinde) wrote :


default-jdk-builddep is meant to be used only as build dependency when generating -gcj variants of a library. It is normally not required by end user.

Claes Wallin (clacke) wrote :

Ok, better example: apt-get build-dep <any-java-package> would likely bring in java-compiler och java2-compiler, which would not be satisfied by an already installed openjdk-6-jdk.

The reason I mentioned default-jdk-builddep is because the jython package depends on it. The name led me to believe that it was a meta-package for java compilation, since default-jdk on lucid i386 is openjdk-6-jdk.

Claes Wallin (clacke) wrote :


Claes Wallin (clacke) wrote :


Onkar Shinde (onkarshinde) wrote :

Ideally packages should build-dep on default-jdk. But a change like this will not happen overnight for all packages. As to the decision if openjdk-6-jdk should provide java2-compiler or not needs to be decided by the maintainers. Please file a separate bug for that.

Claes Wallin (clacke) wrote :

Is that ideal? Depending on a 'Provides:' seems more flexible that depending on a meta-package. And the meta-package in question brings in different jdk's on different platforms, so it doesn't really make builds more predictable either. Anyway, I should probably take this to the relevant mailing list instead of discussing further here.

Onkar Shinde (onkarshinde) wrote :

The reason default-jdk pulls different package on different architecture is because openjdk does not work correctly or is not available on all architectures.
I don't understand how using different JDK's make builds less predictable. They all provide implementation of same APIs.

Claes Wallin (clacke) wrote :

I was just playing devil's advocate with myself and trying to understand why one would want to depend on a package or meta-package instead of a virtual dependency. And it certainly is the case that different implementations differ in how well the implement the APIs and how much they implement.

For me, coming from the outside, it seems more obvious to depend on java2-compiler than on default-jdk. But this is not the forum to discuss this. Instead of spamming this bug with my objections and/or misunderstandings, I will start reading at <> and see where that leads. Thank you for the time you have given me.

On Sat, Mar 06, 2010 at 10:04:23PM -0000, clacke wrote:
> I was just playing devil's advocate with myself and trying to understand
> why one would want to depend on a package or meta-package instead of a
> virtual dependency. And it certainly is the case that different
> implementations differ in how well the implement the APIs and how much
> they implement.

Build-depending on a virtual package means that apt will pick one
essentially at random (of course it *is* deterministic, but the
algorithm is not defined and apt is within its rights to change it at
any time).

Using a metapackage means that the Java maintainers can define
unambiguously and centrally which JDK should be used to build packages,
rather than relying on an undefined algorithm to pick one.

There are many good uses for virtual packages, but in this case a
metapackage is more appropriate.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers