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:
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.