Seconding (thirding?) the idea that keeping JDK 8 for integration with Hadoop is important. Druid's Hadoop integration is built against Hadoop 2.x and that version only supports JDK 8: https://cwiki.apache.org/confluence/display/HADOOP/Hadoop+Java+Versions. We shouldn't drop JDK 8 support until we move to Hadoop 3.3 or later (or drop the Hadoop integration completely).
The costs of keeping things stable on JDK 8 don't seem that high. The ones Suneet raised were: 1) Java 8 is end of life. 2) We can reduce our Travis usage by almost half. As Xavier pointed out, though, (1) isn't wholly fair since there are still plenty of supported enterprise distributions for JDK 8. And ASF Infra hasn't complained to us about (2). To me, the benefits of dropping JDK 8 support don't outweigh the downsides. I do think we should start telling people to deploy on JDK 11 by default, though, and we should focus any future expansion of testing efforts (like perf tests, etc) on JDK 11. I would whole-heartedly support this for the next Druid release. I also agree with Julian that supporting newer JDKs, if feasible, would be good too. On Thu, Nov 12, 2020 at 5:25 PM Xavier Léauté <xav...@confluent.io> wrote: > I agree with Himanshu we should keep JDK 8 support for integrations if we > feel those are important. > > As far as lifecycle goes, JDK 8 support will continue as part of several > linux distributions. > For instance, RedHat has taken on the role of publishing clean upstream > builds for OpenJDK JDK8 > <https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries> and JDK11 > <https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries> updates, > with > support until 2026 <https://access.redhat.com/articles/1299013>. > This means JDK8 will probably not go away for some time with enterprise > users. > > Before we can even deprecate 8 we should at least make 11 (or later) the > default / preferred JDK version. > What would help is to have some first hand accounts of people running > production deployments with 11. > I don't think we have a good sense of whether there are any significant > performance differences between 8 and 11. > We should rule out any regressions before we make it the default. > > I also agree with Julian that we should keep the ball rolling. The biggest > hurdle was (hopefully) to get from 8 to 11, > and the changes for 15 should hopefully be smaller, but it's important we > keep the momentum going. > > Generally I would recommend we support the LTS JDK versions + the latest > Other projects (e.g. Apache Kafka) does the same and builds 8+11+15. > If we are concerned about build times, we can consider running integration > tests for preferred version > and reserve the full suite of JDKs for release candidates. > > Xavier >
