Bug#1006647: libeclipse-jdt-core-java 4.21 breaks Java 8 compatibility for Tomcat

[Per Lundberg]

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