I would be happy with dropping Java 8 support. However, there's a smaller step that we can do now, which is just drop support for *building* with JDK 8. JDK 11 already supports cross-compilation to Java 8 bytecode, and is better at enforcing the rules for Java 8 than JDK 8 was (which is not very rigorous, as it allows some banned internal APIs to be used without any warning).
We already support building with JDK 11 today and targeting Java 8 for runtime, becaise the Gradle configuration enforces Java 8 compatibility when compiling using JDK 11. Furthermore, what is in the master branch already includes code quality checks that can't be run using JDK 8, and only work using JDK 11. So, the only thing really to complete the smaller step of discontinued build support for JDK 8 is to simply stop running CI on JDK 8. We could furthermore add an enforcement check that checks the Java version if you attempt to build using something earlier than JDK 11, so the error is early and obvious. Doing this will still allow users to use libthrift.jar in their Java 8 projects in production. They just won't be able to build libthrift.jar unless they have JDK 11. On Thu, May 12, 2022 at 12:55 PM Triton Circonflexe <tri...@kumal.info> wrote: > > Hello, > > Given that Oracle just announced (in March*) the end of public updates for > Java 8, it seems to be a good time to do that. > > It could be a general rule to consider that the earliest publicly supported > version (usually an LTS) is the oldest version worth some specific efforts > to ensure compatibility (probably applicable to other languages as well). > As long as the older version is not requiring any extra effort it can be > kept but if there is some reason to drop it, like HTTP2 in this case, the > rule applies. > > * https://www.oracle.com/java/technologies/java-se-support-roadmap.html > > My 2 cents, > > Triton. > > Le jeu. 12 mai 2022 à 16:30, Yuxuan Wang <yuxuan.w...@reddit.com.invalid> a > écrit : > > > We do still use jdk8 on our production services, unfortunately. > > > > But a timeline like post-0.17.0 would *probably* work for us, as that gives > > us some time to upgrade to 11 or 17. > > > > On Thu, May 12, 2022 at 8:50 AM Jiayu Liu <ji...@hey.com.invalid> wrote: > > > > > Hi dev@thrift, > > > > > > I've been working on the Java generator and library recently and have > > > revamped the project a little bit, and for the most part, keeping all > > > changes back compatible. > > > > > > Recently I've been thinking of introducing a breaking change: dropping > > > the support of Java 8 and bumping the minimal supported version to Java > > > 11. > > > > > > There are 2 main reasons for doing this: > > > 1. while there are extended support by Oracle or AWS, generally Java 8 > > > is too old [1], while Java 11 is the next LTS version > > > 2. there are good JDK level Http 2 and Web socket support [2] but only > > > added since Java 11 - there are libraries that support Http 2 that can > > > also work in Java 8 but having a non-library dependent code is > > > preferable in many situations > > > > > > Would like to hear more feedback on whether this is a good idea, and > > > when is a good timing (e.g. post release 0.17.0?). > > > > > > [1]: https://www.oracle.com/java/technologies/java-se-support- > > > roadmap.html > > > [2]: > > > > > > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html > > > > > > > > -- > Triton.
