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