I think this is a good move. Let's give users some warning by deprecating it first prior to removal. IMO, good timing would be to deprecate Java 8 in the next major Druid release (Druid 31). That means a doc update, release note update, and updating the start scripts to log a warning that support for Java 8 will be removed soon (if Java 8 is detected).
When we do remove support for Java 8, we should update the "verify-java" script to require DRUID_SKIP_JAVA_CHECK=1 when Java 8 is detected. Gian On 2024/07/16 04:17:06 Abhishek Agarwal wrote: > Hello everyone, > Starting this thread to discuss, if and when, we can drop Java 8 support. > We have been fully supporting Java 11 and Java 17 for a while now. Anyone, > who is looking to upgrade Druid, can safely select either of these LTS Java > runtimes. There are a few important reasons to drop Java 8 support > > - It adds extra burden on build/test pipelines to test all these different > runtimes. We want to shrink this matrix of Java runtime and test suites. > - Being on Java 8 will block us from upgrading dependencies that have > dropped Java 8 support. We can get around it by building profiles and shims > but it adds more complexity. One example is pac4j which is Java 11 based > from 5.x. > - As we drop support for older Java releases, developers can use the > features offered by the more advanced Java versions. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org For additional commands, e-mail: dev-h...@druid.apache.org
