Package: libeclipse-jdt-core-java Version: 3.27.0+eclipse4.21-1 Severity: normal
Dear Maintainer, The 3.27.0+eclipse4.21-1 version of the package has switched to using the 4.21 version of the upstream package (libeclipse-jdt-core-java). This is problematic for us and potentially others who are still forced to use JDK 8, since this version has a strict Java 11 requirement. (This is also listed in the changelog entry for the package.) More so, this package is used as-is in Ubuntu (including the upcoming Ubuntu 22.04 release), which means that the decision to bump the libeclipse-jdt-core-java to a version which only works on Java 11 and greater has significant ramifications to the ecosystem at large. The 4.21 version is not _required_ by Tomcat 9.0.58. It works fine on 4.20 (and perhaps older versions as well, as we also indicate by the libeclipse-jdt-core-java (>= 3.18.0) dependency line for the libtomcat9-java package. I see some ways this could be handled by the Debian project: * Live with it. People who still are using JDK 8 are on their own anyway (Oracle does not support it). Unfortunately, this will cause problems for a number of people, who will be forced to find other ways than using the vendor-provided Tomcat package if their software cannot run on Java 11. * Downgrade the version in Debian to 4.20. This should make our Tomcat work on JDK 8 and 11 alike, and be the "most compatible" approach in this case. I think this would be preferable if possible. I don't know, but I wonder if providing a 4.21-based package in Debian in this case could be an unintentional mistake? I just downloaded the Tomcat 9.0.58 tarball from https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.58/, and it contains the lib/ecj-4.20.jar file, i.e. containing Eclipse JDT version 4.20. I would _guess_ that this is specifically done to avoid enforcing a Java 11 dependency on all Tomcat users. Tomcat 9 (and 10.0) still supports Java 8 in their upstream versions. I'm not in charge of this decision in any way, but I think it does make sense if Debian would consider doing the same. Especially given that Debian is a project which takes backwards compatibility very seriously and works hard to avoid unnecessary breakage for our end users. (In this case, some of "our end users" are using Ubuntu. :) Best regards, Per -- System Information: Debian Release: 11.2 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
