docker-library/docs

tomcat:8 and 8.5 now using jdk11 instead of jdk8

sheyden opened this issue · 3 comments

Since the merge of docker-library/tomcat@d6c16db anyone using tomcat:8 or 8.5 as their base image will automatically be running JDK11 as opposed to JDK8 which was there before:
https://hub.docker.com/layers/tomcat/library/tomcat/8.5.70/images/sha256-0b66d9b8f655f3514475f253d305c8120e5b8adcaad5e0358d899ab97a9f03fb?context=explore

Struggling to trace back the change due to the big template merge, but see screenshots from before and after and the diff:
Screenshot from 2021-09-06 11-04-35
Screenshot from 2021-09-06 11-03-31

tomcat:8.0 is superseded and not receiving updates, so tomcat:8 redirects to tomcat:8.5 as it's the latest in the series and will be using the latest JDK version unless specified (which is 11)

You can specify something like 8.5-jdk8 to use JDK8

OK but where is this documented? Tomcat:8.5 was getting jdk-8 as default (see my screenshot from the commit that was there before last week) and suddenly no more. So this seems like an non deliberate change and a side-effect from the most recent round of commits introducing the templating.

just as FYI: had a local docker-compose stack that worked fine up until last week and broke due to this build. I fully understand the need to be more specific in picking my jdk’s but randomly updating default tags that were on another JDK for a few years seems a bit strange for such a widely used and ‘official’ repo

See docker-library/tomcat#240 (the PR for the commit you linked) -- it has a little bit more detail here:

  • updates the "default" Java version to the latest LTS supported by each version (which should update it to jdk11 in all current cases)

Previously we were hand-picking a Java version per Tomcat version, but there isn't really any canonical guidance on which version should be recommended/used per Tomcat version, so choosing explicitly the "latest LTS" seems like a pretty reasonable compromise.

I'm sorry that it broke your setup, but we really can't avoid breaking users in situations like this -- for example, eventually Java 8 will be deprecated and we'll have to change the default. In this case, the Java 8 variants are still explicitly available so that the fix is easy.