Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hi, On 2022-03-02 17:24, Markus Koschany wrote: (Speaking about tomcat10, I noted the package in experimental is really old - doesn't seem to have been updated for a few years. Do you know if anyone is working on updating the package to e.g. Tomcat 10.0.17 or will it perhaps happen later in the Bookworm release cycle?) I intend to update it in the near future. I believe the initial goal was to make it co-installable with Tomcat 9. Currently there are still some file conflicts which have to be resolved before we can upload Tomcat 10 to unstable. Aha, I see. Good to know. We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal. It would be great if we could use OpenJDK 11 instead but we are not there yet. Alright, I will definitely not suggest it in that case. :D As for the actual libeclipse-jdt-core-java package, is there any particular reason for going with the 4.21 version in Debian unstable & bookworm? I am just curious. It feels like a somewhat odd decision to go with a more recent version than the 4.20 version which Apache bundles in their distribution. But perhaps there are other Debian packages which can find use of the newer package, or has it perhaps just been done to be able to ship the "latest and greatest" version of this package with Bookworm? (I mean: to not ship something which is "old" already at the time of release.) I guess there was no particular reason other than upgrading to the latest available version back then. I have not investigated yet if another Debian package requires 4.21 specifically but since we don't really support Java 8 anymore I think we can just move forward. Tomcat 9 will be gone next year and since we rather have to invest time into fixing OpenJDK 17 bugs than making packages Java 8 compatible, I would say let's keep it as is. Thanks, I'm fine with this. I suggest we keep this bug open until we have the Dependencies line for tomcat9 fixed, as discussed. For our own internal needs, we'll have to find another approach (either creating our own tomcat9 package as you suggested, or spending the time getting our software to be ready for Java 11 (and eventually Java 17) - or both. :-) Given that we will likely have to spend quite an effort moving from tomcat9 to tomcat10 (because of the javax.* to jakarta.* package change), providing this as a package of our own might not be such a bad idea anyway, since it gives us total control of when to roll it our to our customers. (We have built an in-house product which is deployed using Tomcat at a number of on-premise & cloud-based installations, so being too dependent on the Tomcat version which happens to be in Debian unstable => Ubuntu LTS at any given time is perhaps not ideal for us.) Best regards, Per
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hi, Am Mittwoch, dem 02.03.2022 um 16:43 +0200 schrieb Per Lundberg: [...] > (Speaking about tomcat10, I noted the package in experimental is really > old - doesn't seem to have been updated for a few years. Do you know if > anyone is working on updating the package to e.g. Tomcat 10.0.17 or will > it perhaps happen later in the Bookworm release cycle?) I intend to update it in the near future. I believe the initial goal was to make it co-installable with Tomcat 9. Currently there are still some file conflicts which have to be resolved before we can upload Tomcat 10 to unstable. > > Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk > altogether from unstable at this point. The fact that it's present there > is actually a bit confusing, since it gives the (completely false) > impression that JDK 8 will be supported in future versions of Debian. If > you agree, I can file a separate removal bug on that package. (I'm not > currently a Debian maintainer myself, so I cannot help out more than > that. ;) We still need OpenJDK 8 to bootstrap Kotlin. Please don't ask for its removal. It would be great if we could use OpenJDK 11 instead but we are not there yet. > > As for the actual libeclipse-jdt-core-java package, is there any > particular reason for going with the 4.21 version in Debian unstable & > bookworm? I am just curious. It feels like a somewhat odd decision to go > with a more recent version than the 4.20 version which Apache bundles in > their distribution. But perhaps there are other Debian packages which > can find use of the newer package, or has it perhaps just been done to > be able to ship the "latest and greatest" version of this package with > Bookworm? (I mean: to not ship something which is "old" already at the > time of release.) I guess there was no particular reason other than upgrading to the latest available version back then. I have not investigated yet if another Debian package requires 4.21 specifically but since we don't really support Java 8 anymore I think we can just move forward. Tomcat 9 will be gone next year and since we rather have to invest time into fixing OpenJDK 17 bugs than making packages Java 8 compatible, I would say let's keep it as is. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hi Markus, On 2022-03-02 14:15, Markus Koschany wrote: As a matter of fact OpenJDK 11 is the only supported Java version in oldstable, stable and testing right now. We plan to release with Java 17 next year and one of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are right that we should tighten the dependency to java11-runtime-headless to avoid any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the moment. If you cannot upgrade your application to Java 11, then you could create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java to 4.20 again. Thanks for clarifying these things and mentioning the plan from the Debian Java maintainers in this case. I remember discussing something similar (JDK 11 only to be supported) a few years ago with you in fact; the problem was with visualvm at that time. :) (Speaking about tomcat10, I noted the package in experimental is really old - doesn't seem to have been updated for a few years. Do you know if anyone is working on updating the package to e.g. Tomcat 10.0.17 or will it perhaps happen later in the Bookworm release cycle?) Also, I wonder if it wouldn't even make sense to remove openjdk-8-jdk altogether from unstable at this point. The fact that it's present there is actually a bit confusing, since it gives the (completely false) impression that JDK 8 will be supported in future versions of Debian. If you agree, I can file a separate removal bug on that package. (I'm not currently a Debian maintainer myself, so I cannot help out more than that. ;) As for the actual libeclipse-jdt-core-java package, is there any particular reason for going with the 4.21 version in Debian unstable & bookworm? I am just curious. It feels like a somewhat odd decision to go with a more recent version than the 4.20 version which Apache bundles in their distribution. But perhaps there are other Debian packages which can find use of the newer package, or has it perhaps just been done to be able to ship the "latest and greatest" version of this package with Bookworm? (I mean: to not ship something which is "old" already at the time of release.) Best regards, Per
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
Hello Per, Am Mittwoch, dem 02.03.2022 um 12:54 +0200 schrieb Per Lundberg: > reassign 1006647 tomcat9 > thanks > > This might better belong to this package, since the problem is that > tomcat9-common depends on default-jre-headless | java8-runtime-headless > > java8-runtime, while in reality it requires Java 11. (because of > Eclipse JDT 4.21, see original bug report for details) > > If we are unable to fully resolve this, I think that we should at least > fix these incorrect dependencies to make the package depend on > "default-jre-headless | java11-runtime-headless | java11-runtime" > instead. But as previously mentioned, I would much rather see us move to > Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at > some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is > inevitable). As a matter of fact OpenJDK 11 is the only supported Java version in oldstable, stable and testing right now. We plan to release with Java 17 next year and one of our goals is to ship only Tomcat 10 in Debian 12 "Bookworm". I think you are right that we should tighten the dependency to java11-runtime-headless to avoid any confusion but as I said, OpenJDK 11 is the only supported JDK/JRE at the moment. If you cannot upgrade your application to Java 11, then you could create a custom Tomcat 9 package or simply downgrade libeclipse-jdt-core-java to 4.20 again. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
reassign 1006647 tomcat9 thanks This might better belong to this package, since the problem is that tomcat9-common depends on default-jre-headless | java8-runtime-headless | java8-runtime, while in reality it requires Java 11. (because of Eclipse JDT 4.21, see original bug report for details) If we are unable to fully resolve this, I think that we should at least fix these incorrect dependencies to make the package depend on "default-jre-headless | java11-runtime-headless | java11-runtime" instead. But as previously mentioned, I would much rather see us move to Eclipse JDT 4.20 instead so we can retain Java 8 support until Debian at some point upgrades to Tomcat 10.1 (at which point requiring Java 11 is inevitable). Best regards, Per
Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat
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
