Updated to 16.0.0 on Ubuntu 22.04.3 LTS: XWiki fails to start

Help / Discuss
#1

Hi! It is the first time I found any issues while updating by using Debian packages.

After sudo apt update && sudo apt upgrade last Monday, I accepted to update to XWiki 16.0.0 from XWiki 15.10.5.

It ran in a Ubuntu server:

rjr@IGFAE-MU-07-MacPro:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"

Java is also up-to-date:

rjr@IGFAE-MU-07-MacPro:~$ java -version
openjdk version "18.0.2-ea" 2022-07-19
OpenJDK Runtime Environment (build 18.0.2-ea+9-Ubuntu-222.04)
OpenJDK 64-Bit Server VM (build 18.0.2-ea+9-Ubuntu-222.04, mixed mode, sharing)

The complete log in catalina.out after starting Tomcat is:

[2024-02-02 17:50:27] [info] NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Server version name:   Apache Tomcat/9.0.58 (Ubuntu)
[2024-02-02 17:50:28] [info] Server built:          Jan 6 1970 15:09:28 UTC
[2024-02-02 17:50:28] [info] Server version number: 9.0.58.0
[2024-02-02 17:50:28] [info] OS Name:               Linux
[2024-02-02 17:50:28] [info] OS Version:            6.5.0-15-generic
[2024-02-02 17:50:28] [info] Architecture:          amd64
[2024-02-02 17:50:28] [info] Java Home:             /usr/lib/jvm/java-11-openjdk-amd64
[2024-02-02 17:50:28] [info] JVM Version:           11.0.21+9-post-Ubuntu-0ubuntu122.04
[2024-02-02 17:50:28] [info] JVM Vendor:            Ubuntu
[2024-02-02 17:50:28] [info] CATALINA_BASE:         /var/lib/tomcat9
[2024-02-02 17:50:28] [info] CATALINA_HOME:         /usr/share/tomcat9
[2024-02-02 17:50:28] [info] Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
[2024-02-02 17:50:28] [info] Command line argument: -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
[2024-02-02 17:50:28] [info] Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2024-02-02 17:50:28] [info] Command line argument: -Djava.awt.headless=true
[2024-02-02 17:50:28] [info] Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
[2024-02-02 17:50:28] [info] Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
[2024-02-02 17:50:28] [info] Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
[2024-02-02 17:50:28] [info] Command line argument: -Dignore.endorsed.dirs=
[2024-02-02 17:50:28] [info] Command line argument: -Dcatalina.base=/var/lib/tomcat9
[2024-02-02 17:50:28] [info] Command line argument: -Dcatalina.home=/usr/share/tomcat9
[2024-02-02 17:50:28] [info] Command line argument: -Djava.io.tmpdir=/tmp
[2024-02-02 17:50:28] [info] Loaded Apache Tomcat Native library [1.2.31] using APR version [1.7.0].
[2024-02-02 17:50:28] [info] APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true], UDS [true].
[2024-02-02 17:50:28] [info] APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true]
[2024-02-02 17:50:28] [info] OpenSSL successfully initialized [OpenSSL 3.0.2 15 Mar 2022]
[2024-02-02 17:50:28] [info] Initializing ProtocolHandler ["http-nio-8080"]
[2024-02-02 17:50:28] [info] Server initialization in [776] milliseconds
[2024-02-02 17:50:28] [warning] Name = igfae_bbdd Property maxActive is not used in DBCP2, use maxTotal instead. maxTotal default value is 8. You have set value of "10" for "maxActive" property, which is being ignored.
[2024-02-02 17:50:28] [warning] Name = igfae_bbdd Property maxWait is not used in DBCP2 , use maxWaitMillis instead. maxWaitMillis default value is PT-0.001S. You have set value of "-1" for "maxWait" property, which is being ignored.
[2024-02-02 17:50:28] [info] Starting service [Catalina]
[2024-02-02 17:50:28] [info] Starting Servlet engine: [Apache Tomcat/9.0.58 (Ubuntu)]
[2024-02-02 17:50:28] [info] Deploying deployment descriptor [/etc/tomcat9/Catalina/localhost/manager.xml]
[2024-02-02 17:50:28] [warning] The path attribute with value [/manager] in deployment descriptor [/etc/tomcat9/Catalina/localhost/manager.xml] has been ignored
[2024-02-02 17:50:30] [info] At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2024-02-02 17:50:30] [info] Deployment of deployment descriptor [/etc/tomcat9/Catalina/localhost/manager.xml] has finished in [1,315] ms
[2024-02-02 17:50:30] [info] Deploying deployment descriptor [/etc/tomcat9/Catalina/localhost/xwiki.xml]
[2024-02-02 17:50:30] [warning] The path attribute with value [/xwiki] in deployment descriptor [/etc/tomcat9/Catalina/localhost/xwiki.xml] has been ignored
[2024-02-02 17:50:31] [crit] One or more listeners failed to start. Full details will be found in the appropriate container log file
[2024-02-02 17:50:31] [crit] Context [/xwiki] startup failed due to previous errors
[2024-02-02 17:50:31] [warning] Failed to clear soft references from ObjectStreamClass$Caches for web application [xwiki]
[2024-02-02 17:50:31] [warning] java.lang.ClassCastException: class java.io.ObjectStreamClass$Caches$1 cannot be cast to class java.util.Map (java.io.ObjectStreamClass$Caches$1 and java.util.Map are in module java.base of loader 'bootstrap')
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.loader.WebappClassLoaderBase.clearCache(WebappClassLoaderBase.java:2325)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesObjectStreamClassCaches(WebappClassLoaderBase.java:2300)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.loader.WebappClassLoaderBase.clearReferences(WebappClassLoaderBase.java:1669)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.loader.WebappClassLoaderBase.stop(WebappClassLoaderBase.java:1597)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.loader.WebappLoader.stopInternal(WebappLoader.java:463)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5515)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:187)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:690)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1889)
[2024-02-02 17:50:31] [warning]     at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
[2024-02-02 17:50:31] [warning]     at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[2024-02-02 17:50:31] [warning]     at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
[2024-02-02 17:50:31] [warning]     at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:583)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1618)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:319)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:946)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
[2024-02-02 17:50:31] [warning]     at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[2024-02-02 17:50:31] [warning]     at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
[2024-02-02 17:50:31] [warning]     at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.Catalina.start(Catalina.java:772)
[2024-02-02 17:50:31] [warning]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2024-02-02 17:50:31] [warning]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[2024-02-02 17:50:31] [warning]     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[2024-02-02 17:50:31] [warning]     at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345)
[2024-02-02 17:50:31] [warning]     at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:480)
[2024-02-02 17:50:31] [info] Deployment of deployment descriptor [/etc/tomcat9/Catalina/localhost/xwiki.xml] has finished in [1,205] ms
[2024-02-02 17:50:31] [info] Deploying deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml]
[2024-02-02 17:50:31] [warning] The path attribute with value [/host-manager] in deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml] has been ignored
[2024-02-02 17:50:32] [info] At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2024-02-02 17:50:32] [info] Deployment of deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml] has finished in [738] ms
[2024-02-02 17:50:32] [info] Deploying web application directory [/var/lib/tomcat9/webapps/ROOT]
[2024-02-02 17:50:32] [info] At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
[2024-02-02 17:50:32] [info] Deployment of web application directory [/var/lib/tomcat9/webapps/ROOT] has finished in [688] ms
[2024-02-02 17:50:32] [info] Starting ProtocolHandler ["http-nio-8080"]
[2024-02-02 17:50:32] [info] Server startup in [4102] milliseconds

It seems that the relevant lines are:

[2024-02-02 17:50:31] [crit] One or more listeners failed to start. Full details will be found in the appropriate container log file
[2024-02-02 17:50:31] [crit] Context [/xwiki] startup failed due to previous errors

Could you help me with this issue? How can I find “the appropriate container log”?

Thanks!

#2

I’m having the same problem. I was about to put a new site into production this weekend, did one final update, and now I get a Tomcat 404 message: “The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.”

My Apache proxy and Tomcat both report as running when using systemctl.

The Tomcat logs show:

02-Feb-2024 11:44:03.452 SEVERE [main] org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [org.xwiki.container.servlet.XWikiServletContextListener]
	java.lang.UnsupportedClassVersionError: org/xwiki/container/servlet/XWikiServletContextListener has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0 (unable to load class [org.xwiki.container.servlet.XWikiServletContextListener])

In my case, I’m running Ubuntu 20.04 LTS which only has openjdk 17 available.

openjdk 17.0.9 2023-10-17
OpenJDK Runtime Environment (build 17.0.9+9-Ubuntu-120.04)
OpenJDK 64-Bit Server VM (build 17.0.9+9-Ubuntu-120.04, mixed mode, sharing)
#3

This sentence is a no-sense. I should have simply written that the version of Java installed is Java 18.

#4

I’m trying to understand XWiki Java Support Strategy.

Before upgrading to XWiki 16.0.0, I read the first bulleted point in its frame on the download page. It reads Requires Java 17+.

image

I interpreted it as “XWiki 16.0.0 will run on Java 17 or newer”. Is it correct, please?

Reading @Redhorse post and looking back into my own log, I feel lost. The class version 61 is the class version of Java 17, isn’t it? I could understand that dropping Java 11 would somehow affect the support of versions 12 to 16, but @Redhorse is running Java 17.

#5

Here is the answer! I must apologize for the noise! XWiki is running on Java 11, also installed in the server. So, the question now is to learn how to tell XWiki how to run on the default Java set on the box or on a specific version, always 17+. @Redhorse, could it be also your case?

HTH!

1 Like
#6

I agree with your interpretation that based on their Java Support Strategy, Java 17 is supported for XWiki 16.0.0.

From my Tomcat’s localhost error log it appears that they compiled the XWikiServletContextListener class with a later version of Java than they claim to support. So if that one module were compiled with Java 18, it will have problems working with the rest of the package that was compiled with Java 17. At least that is how I interpret it. I don’t have much experience with Java, so it may be something else - error messages are funny that way.

#7

I just created an issue in Jira: Upgrade to XWiki 16.0.0 broken on Ubuntu 20.04.

#8

Ricardo, if you have both versions of Java installed, you can change the default by running:
sudo update-alternatives --config java.
You will then see a list like this (but with other version numbers):

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-17-openjdk-amd64/bin/java      1711      auto mode
  1            /usr/lib/jvm/java-11-openjdk-amd64/bin/java      1111      manual mode
  2            /usr/lib/jvm/java-17-openjdk-amd64/bin/java      1711      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press <enter> to keep the current choice[*], or type selection number:

Just type in the number to the left of the version you want and hit enter. Then run java --version to verify that it changed correctly. Then XWiki (and any other Java apps) should use the new version. You might need to restart your Tomcat server for it to take effect.

In my case, I was already using Java 17 when I installed XWiki, so I assume that it what XWiki was running on.

UPDATE:
Your last question got me digging in the config files. I got it working. My installation was apparently defaulting to Java 11, so I had to explicitly point it to Java 17. Here is how I fixed it:

Open /etc/default/tomcat9

Add the following line near the top:
JAVA_HOME=/usr/lib/jvm/java-1.17.0-openjdk-amd64

Save and restart tomcat:
sudo systemctl restart tomcat9

1 Like
#9

Thanks, @Redhorse. Do you understand why this line is needed by Tomcat 9 when Java version is set to auto, pointing to Java 17 in your case and to Java 18 in mine, and java -version reports the correct version is set up?

#10

@Ricardo_Rodriguez, As I understand it, when you don’t explicitly tell Tomcat which version of Java to use, it will look for it in the most common locations. In Ununtu’s case, this will be at /usr/lib/jvm.

In one of my earlier posts where I listed the versions installed on my system, Java 11 was the first listed (line 0 doesn’t count - it just shows the current selection). This order is based on a pure alphabetical listing where 11 comes before 17 and 8. So with XWiki 15.x.x, Tomcat picked Java 11 as the first version it found, which worked. Then after the upgrade, it still picked 11 as the first one it found, which didn’t work for XWiki, but Tomcat doesn’t know that.

What we were both assuming was that Tomcat (like many other Java applications) would look to see which version was set as the system default as reported by java --version, which unfortunately was wrong. This makes some sense because a system might have multiple Java applications, each with different version requirements. Therefore, the system might be configured for an incompatible version in order to support other applications.

This is just my guess based on the behavior. If I’m wrong, hopefully someone more knowledgeable about the inner workings of Tomcat will correct me.

#11

Thanks, @Redhorse! I started yesterday to draft an answer. Yours helps me now! I agree, this is not a XWiki issue, but it affects the XWiki functioning. I think it is worth to describe and document it here at some extent.

java -version show the Java used by the command line, not the Java used by Tomcat at startup. Not sure about how this is set up.

/etc/default/tomcat9, in my server, reads:

# The home directory of the Java development kit (JDK). You need at least
# JDK version 8. If JAVA_HOME is not set, some common directories for
# OpenJDK and the Oracle JDK are tried.
#JAVA_HOME=/usr/lib/jvm/java-8-openjdk

Thus, the part of your answer about picking Java version by alphabetic listing seems to make sense: if we set JAVA_HOME there, we are in the safe side! But also, if you list /usr/lib/jvm, you will find:

rjr@IGFAE-MU-07-MacPro:/usr/lib/jvm$ ls -l
total 20
lrwxrwxrwx 1 root root   25 Mar 24  2022 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root   21 Aug 25 00:33 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
lrwxrwxrwx 1 root root   21 Oct 19 09:43 java-1.17.0-openjdk-amd64 -> java-17-openjdk-amd64
lrwxrwxrwx 1 root root   21 Jul 22  2022 java-1.18.0-openjdk-amd64 -> java-18-openjdk-amd64`Preformatted text`
drwxr-xr-x 9 root root 4096 Nov 30 06:31 java-11-openjdk-amd64
drwxr-xr-x 7 root root 4096 Jan 31 08:16 java-17-openjdk-amd64
drwxr-xr-x 9 root root 4096 Oct  2 14:51 java-18-openjdk-amd64
drwxr-xr-x 2 root root 4096 Nov 30 06:31 openjdk-11
drwxr-xr-x 2 root root 4096 Oct  2 14:51 openjdk-18
rjr@IGFAE-MU-07-MacPro:/usr/lib/jvm$

There is a symlink there in, default-java, pointing to Java 11!

If I remove it, create a new one pointing to Java 18, comment out JAVA_HOME in /etc/default/tomcat9, and restart Tomcat 9, XWiki starts up.

This defaul-java symlink should be managed by update-alternatives. This doesn’t happen here. It seems to me that I have, perhaps we have, a messy Java installation. I remember, but not completely sure, I installed manually Java 18. No idea about Java 11 and Java 17. As update-alternatives is an APK thing, perhaps I broke something. Removing and recreating the defaul-java symlink, works.

I understand now more about how Java works in Ubuntu. I hope to find this thread when XWiki removes support for Java 17 in 2026! :slight_smile:

Tomcat Errors After Upgrade from 15.10.1 to 16.0.0
#12

It is correct, yes.

#13

Btw, I had the same problem just recently, and the problem was that the java link was not updated correctty (despite the update-alternatives --config java told me so).

However when I lokked at:

ls -l /usr/lib/jvm/
lrwxrwxrwx 1 root root   25 Dec 30  2018 default-java -> java-1.11.0-openjdk-amd64
lrwxrwxrwx 1 root root   21 Jan 17  2020 java-1.11.0-openjdk-amd64 -> java-11-openjdk-amd64
drwxr-xr-x 7 root root 4096 Jan 24 15:49 java-11-openjdk-amd64
lrwxrwxrwx 1 root root   21 Jan 31 00:08 java-1.17.0-openjdk-amd64 -> java-17-openjdk-amd64
drwxr-xr-x 7 root root 4096 Feb  3 22:59 java-17-openjdk-amd64

I think the issue was that the link from default-java was pointing to java-1.11.0-openjdk-amd64, not java-11-openjdk-amd64, which might have confused the update-alternatives

Fix:

  cd /usr/lib/jvm
  rm default-java; ln -s java-17-openjdk-amd64 default-java

(I am not sure if that issue reappears next time the java version is switched. Last time I did not have the issue.)

#14

Good point! As I said above, we will see in 2026! In the meantime, updates-alternatives is a new fragile point to pay attention to!

#15

Thanks @ClemensRobbenhaar, I wasn’t aware of the default-java link. I would have expected update-alternatives to change something like that. Knowing this will save me a lot of trouble in the future.