Thank you all for the good feedback! I've been thinking about the tradeoff here (the benefit of reduced maintenance and newer API versus the benefit of keeping back compatibility esp. for people still on JDK8). I think there is a way to best fit most people's interest:
We can move the currently gradle managed project into a multi project build [1]: 1. sub-project `libthrift`, which is the current Java library, to be configured with --release flag [2] to target Java 8 (class file version, APIs) 2. sub-project `cross-test`, which is split out from the existing project, to only contain cross test code, this way we can follow more gradle convention, reduce customized configurations (e.g. using `application` plugin instead of manually creating start scripts), and have stronger encapsulation 3. sub-project `libthrift-jdk11`, similar to what Kotlin does [3] with their stdlib, to target JDK 11+. Both `libthrift` and this need to be published, the added overhead for publishing should be minimal given they share same config and process (signing, verification, etc.), and for users who are not eager to use newer version, no changes are needed on their side. Regardless of making this change or not, I think we can start using Java 11 to compile with --release 8 flag, to ensure better encapsulation and version compatibility. [1]: https://docs.gradle.org/current/userguide/multi_project_builds.html#multi_project_builds [2]: https://openjdk.java.net/jeps/247 [3]: https://kotlinlang.org/docs/maven.html#dependencies On May 13, 2022, yuxuan wang <yuxuan.w...@reddit.com.invalid> wrote: > Yes I saw the Oracle roadmap page. Even according to the latest > version of > the page, it still says that jdk 8 has "Extended Support Until" > December > 2030, the one ending was "Premier Support Until" (which ended at March > 2022). So I think this is quite different from some cases in other > languages: > > 1. For python, the official doc clearly stated that [1] all the > versions up > to 3.6 are already end-of-life, so we can drop support for all already > eol'd versions [2] > 2. For go, the official doc clearly stated that [3] only the latest 2 > major > releases are supported. It also have strong backward compatibility > guarantee (so the risk of production service to upgrade the version of > go > they are using is minimal), so thrift has a matching policy to only > support > the officially supported 2 go versions at the time of release [4] > > In jdk 8's case, it's not officially eol'd yet, and there's still > non-trivial risk for a production service to switch from jdk 8 to jdk > 11. I > do agree that the project needs to move forward and not be tied with > JDK 8 > support forever (as in, until December 2030), so having a timeline to > give > users time to upgrade is more reasonable than just dropping it. > > [1]: https://devguide.python.org/devcycle/#end-of-life-branches > [2]: https://issues.apache.org/jira/browse/THRIFT-5537 > [3]: https://go.dev/doc/devel/release#policy > [4]: > https://github.com/apache/thrift/blob/master/lib/go/README.md#suppored- > go-releases > > On Thu, May 12, 2022 at 9:55 AM 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. > >
