openjdk team mailing list archive

[Bart Vanhaute <bart.vanhaute@xxxxxxxxx>]

Package: openjdk-7-jdk
Version: 7u79-2.5.5-1
Severity: normal

The priority for update-alternatives of the java and javac in the openjdk-7
package are not the same. On my system, I have three versions of openjdk
installed (6, 7, and 8).

$ update-alternatives --display javac
javac - auto mode
  link currently points to /usr/lib/jvm/java-8-openjdk-amd64/bin/javac
/usr/lib/jvm/java-6-openjdk-amd64/bin/javac - priority 1061
  slave javac.1.gz: /usr/lib/jvm/java-6-openjdk-amd64/man/man1/javac.1.gz
/usr/lib/jvm/java-7-openjdk-amd64/bin/javac - priority 1051
  slave javac.1.gz: /usr/lib/jvm/java-7-openjdk-amd64/man/man1/javac.1.gz
/usr/lib/jvm/java-8-openjdk-amd64/bin/javac - priority 1069
  slave javac.1.gz: /usr/lib/jvm/java-8-openjdk-amd64/man/man1/javac.1.gz
Current 'best' version is '/usr/lib/jvm/java-8-openjdk-amd64/bin/javac'.
$ update-alternatives --display java
java - auto mode
  link currently points to /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java - priority 1061
  slave java.1.gz: /usr/lib/jvm/java-6-openjdk-amd64/jre/man/man1/java.1.gz
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java - priority 1071
  slave java.1.gz: /usr/lib/jvm/java-7-openjdk-amd64/jre/man/man1/java.1.gz
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java - priority 1069
  slave java.1.gz: /usr/lib/jvm/java-8-openjdk-amd64/jre/man/man1/java.1.gz
Current 'best' version is '/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java'.

Note that javac points to the one in openjdk-8, while java points to openjdk-7.


As a result, when I compile a java source file with javac, it is not possible
to execute it with java because of the class version:

$ javac t.java
$ java -cp . t
Exception in thread "main" java.lang.UnsupportedClassVersionError: t :
Unsupported major.minor version 52.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
        at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
        at
sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)


As a workaround, I can configure the javac alternative manually to point to the
one from openjdk-8, but I my opinion, that should not be necessary and the
default should just work.




-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-7-jdk depends on:
ii  libc6          2.19-18
ii  libx11-6       2:1.6.3-1
ii  openjdk-7-jre  7u79-2.5.5-1

Versions of packages openjdk-7-jdk recommends:
ii  libxt-dev  1:1.1.4-1+b1

Versions of packages openjdk-7-jdk suggests:
pn  openjdk-7-demo    <none>
ii  openjdk-7-source  7u79-2.5.5-1
pn  visualvm          <none>

-- no debconf information