Inconsistent 'Provides' for different java compilers/runtimes

Bug #189953 reported by Onkar Shinde
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
icedtea-java7 (Ubuntu)
Invalid
Wishlist
Matthias Klose
openjdk-6 (Ubuntu)
Fix Released
Undecided
Unassigned

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.

Revision history for this message
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
Revision history for this message
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/README.alternatives.in: fix update-java-alternatives examples

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

Revision history for this message
Matthias Klose (doko) wrote :

already done in the vcs.

Changed in icedtea-java7:
status: Triaged → In Progress
Revision history for this message
Daniel Hahler (blueyed) wrote :

Do you mean http://bazaar.launchpad.net/~ubuntu-java/uj/openjdk6 ?
Will this make it into Hardy?

Changed in icedtea-java7:
assignee: nobody → doko
Revision history for this message
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
Revision history for this message
Matthias Klose (doko) wrote :

icedtea-java7 is now removed from hardy

Changed in icedtea-java7:
status: In Progress → Invalid
Revision history for this message
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.

Revision history for this message
Onkar Shinde (onkarshinde) wrote :

@clacke,

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.

Revision history for this message
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.

Revision history for this message
Claes Wallin (clacke) wrote :

s,och,and/or,

Revision history for this message
Claes Wallin (clacke) wrote :

s,depends,build-depends,

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 <https://wiki.ubuntu.com/JavaPolicy> and see where that leads. Thank you for the time you have given me.

Revision history for this message
Colin Watson (cjwatson) wrote : Re: [Bug 189953] Re: Inconsistent 'Provides' for different java compilers/runtimes

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  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.