You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Jiayu Liu <ji...@hey.com.INVALID> on 2022/05/12 15:50:40 UTC
Dropping Java 8 support?
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
Re: Dropping Java 8 support?
Posted by Christopher <ct...@apache.org>.
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 <tr...@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 <yu...@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.
Re: Dropping Java 8 support?
Posted by Jiayu Liu <ji...@hey.com.INVALID>.
Hi there has been an update on this topic at
https://github.com/apache/thrift/pull/2785 - feel free to chime in and
provide additional context and discuss.
On September 16, 2022, yuxuan wang <yu...@reddit.com.invalid>
wrote:
> no objections from me :)
>
> thank you for looking into it!
>
> On Thu, Sep 15, 2022 at 6:03 PM Jiayu Liu <ji...@hey.com.invalid>
> wrote:
>
> > After 0.17 release i am proposing once again to upgrade to Java 11
> > minimal version. Any more feedback or concerns?
> >
> > On May 14, 2022, yuxuan wang <yu...@reddit.com.invalid> wrote:
> > > +1 for using jdk11 to build jdk8 compatible jar for now, and
> dropping
> > > jdk8
> > > support later (we are already planning/working on migrating to
> jdk11
> > > internally).
> > >
> > > On Fri, May 13, 2022 at 1:25 AM Christopher <ct...@apache.org>
> > > wrote:
> > >
> > > > On Fri, May 13, 2022 at 1:20 AM Jiayu Liu
> <ji...@hey.com.invalid>
> > > wrote:
> > > > >
> > > > > Regarding point 2 - the lib/kotlin has its own cross tests
> which
> > > tests
> > > > > kotlin generator code, the lib/java has all along had its own
> > > cross
> > > > > tests, which currently live in lib/java/src/crossTests. These
> two
> > > are
> > > > > not related.
> > > >
> > > > Thanks for the clarification.
> > > >
> > > > >
> > > > > Regarding point 3 - the added module does not contain
> libthrift
> > > code but
> > > > > only the parts that are JDK11 specific for example the new JDK
> > > http
> > > > > client. I did not mean to compile the same code using two
> > > different
> > > > > targets but rather split out JDK11 Api dependent code so the
> > > libthrift
> > > > > continues to run on Java 8
> > > >
> > > > Okay, I understand now. Thanks. Right now, there isn't any JDK11
> API
> > > > dependent code. If we reach the point where somebody wants to
> write
> > > > some for a feature that is exclusive to JDK 11 and later, then I
> > > think
> > > > that would be a good reason to consider dropping 8, rather than
> > > > maintain two.
> > > >
> >
--
Sent with HEY <https://hey.com/sent>
Re: Dropping Java 8 support?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
no objections from me :)
thank you for looking into it!
On Thu, Sep 15, 2022 at 6:03 PM Jiayu Liu <ji...@hey.com.invalid> wrote:
> After 0.17 release i am proposing once again to upgrade to Java 11
> minimal version. Any more feedback or concerns?
>
> On May 14, 2022, yuxuan wang <yu...@reddit.com.invalid> wrote:
> > +1 for using jdk11 to build jdk8 compatible jar for now, and dropping
> > jdk8
> > support later (we are already planning/working on migrating to jdk11
> > internally).
> >
> > On Fri, May 13, 2022 at 1:25 AM Christopher <ct...@apache.org>
> > wrote:
> >
> > > On Fri, May 13, 2022 at 1:20 AM Jiayu Liu <ji...@hey.com.invalid>
> > wrote:
> > > >
> > > > Regarding point 2 - the lib/kotlin has its own cross tests which
> > tests
> > > > kotlin generator code, the lib/java has all along had its own
> > cross
> > > > tests, which currently live in lib/java/src/crossTests. These two
> > are
> > > > not related.
> > >
> > > Thanks for the clarification.
> > >
> > > >
> > > > Regarding point 3 - the added module does not contain libthrift
> > code but
> > > > only the parts that are JDK11 specific for example the new JDK
> > http
> > > > client. I did not mean to compile the same code using two
> > different
> > > > targets but rather split out JDK11 Api dependent code so the
> > libthrift
> > > > continues to run on Java 8
> > >
> > > Okay, I understand now. Thanks. Right now, there isn't any JDK11 API
> > > dependent code. If we reach the point where somebody wants to write
> > > some for a feature that is exclusive to JDK 11 and later, then I
> > think
> > > that would be a good reason to consider dropping 8, rather than
> > > maintain two.
> > >
>
Re: Dropping Java 8 support?
Posted by Mario Emmenlauer <ma...@emmenlauer.de>.
On 16.09.22 03:02, Jiayu Liu wrote:
> After 0.17 release i am proposing once again to upgrade to Java 11
> minimal version. Any more feedback or concerns?
That sounds good for me! Thanks for looking into this!
All the best,
Mario
Re: Dropping Java 8 support?
Posted by Jiayu Liu <ji...@hey.com.INVALID>.
After 0.17 release i am proposing once again to upgrade to Java 11
minimal version. Any more feedback or concerns?
On May 14, 2022, yuxuan wang <yu...@reddit.com.invalid> wrote:
> +1 for using jdk11 to build jdk8 compatible jar for now, and dropping
> jdk8
> support later (we are already planning/working on migrating to jdk11
> internally).
>
> On Fri, May 13, 2022 at 1:25 AM Christopher <ct...@apache.org>
> wrote:
>
> > On Fri, May 13, 2022 at 1:20 AM Jiayu Liu <ji...@hey.com.invalid>
> wrote:
> > >
> > > Regarding point 2 - the lib/kotlin has its own cross tests which
> tests
> > > kotlin generator code, the lib/java has all along had its own
> cross
> > > tests, which currently live in lib/java/src/crossTests. These two
> are
> > > not related.
> >
> > Thanks for the clarification.
> >
> > >
> > > Regarding point 3 - the added module does not contain libthrift
> code but
> > > only the parts that are JDK11 specific for example the new JDK
> http
> > > client. I did not mean to compile the same code using two
> different
> > > targets but rather split out JDK11 Api dependent code so the
> libthrift
> > > continues to run on Java 8
> >
> > Okay, I understand now. Thanks. Right now, there isn't any JDK11 API
> > dependent code. If we reach the point where somebody wants to write
> > some for a feature that is exclusive to JDK 11 and later, then I
> think
> > that would be a good reason to consider dropping 8, rather than
> > maintain two.
> >
Re: Dropping Java 8 support?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
+1 for using jdk11 to build jdk8 compatible jar for now, and dropping jdk8
support later (we are already planning/working on migrating to jdk11
internally).
On Fri, May 13, 2022 at 1:25 AM Christopher <ct...@apache.org> wrote:
> On Fri, May 13, 2022 at 1:20 AM Jiayu Liu <ji...@hey.com.invalid> wrote:
> >
> > Regarding point 2 - the lib/kotlin has its own cross tests which tests
> > kotlin generator code, the lib/java has all along had its own cross
> > tests, which currently live in lib/java/src/crossTests. These two are
> > not related.
>
> Thanks for the clarification.
>
> >
> > Regarding point 3 - the added module does not contain libthrift code but
> > only the parts that are JDK11 specific for example the new JDK http
> > client. I did not mean to compile the same code using two different
> > targets but rather split out JDK11 Api dependent code so the libthrift
> > continues to run on Java 8
>
> Okay, I understand now. Thanks. Right now, there isn't any JDK11 API
> dependent code. If we reach the point where somebody wants to write
> some for a feature that is exclusive to JDK 11 and later, then I think
> that would be a good reason to consider dropping 8, rather than
> maintain two.
>
Re: Dropping Java 8 support?
Posted by Christopher <ct...@apache.org>.
On Fri, May 13, 2022 at 1:20 AM Jiayu Liu <ji...@hey.com.invalid> wrote:
>
> Regarding point 2 - the lib/kotlin has its own cross tests which tests
> kotlin generator code, the lib/java has all along had its own cross
> tests, which currently live in lib/java/src/crossTests. These two are
> not related.
Thanks for the clarification.
>
> Regarding point 3 - the added module does not contain libthrift code but
> only the parts that are JDK11 specific for example the new JDK http
> client. I did not mean to compile the same code using two different
> targets but rather split out JDK11 Api dependent code so the libthrift
> continues to run on Java 8
Okay, I understand now. Thanks. Right now, there isn't any JDK11 API
dependent code. If we reach the point where somebody wants to write
some for a feature that is exclusive to JDK 11 and later, then I think
that would be a good reason to consider dropping 8, rather than
maintain two.
Re: Dropping Java 8 support?
Posted by Jiayu Liu <ji...@hey.com.INVALID>.
Regarding point 2 - the lib/kotlin has its own cross tests which tests
kotlin generator code, the lib/java has all along had its own cross
tests, which currently live in lib/java/src/crossTests. These two are
not related.
Note in lib/java we had to modify sourceset via gradle config, and use
shadow jar plugin to package the cross test shadow jar, and also
configure start script to generate the cross test runner, most of which
can be removed if we switch to a multi project setup and it was what i
was proposing.
Regarding point 3 - the added module does not contain libthrift code but
only the parts that are JDK11 specific for example the new JDK http
client. I did not mean to compile the same code using two different
targets but rather split out JDK11 Api dependent code so the libthrift
continues to run on Java 8
On May 13, 2022, Christopher <ct...@apache.org> wrote:
> On Thu, May 12, 2022 at 9:05 PM Jiayu Liu <ji...@hey.com.invalid>
> wrote:
> > 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)
>
> This is already what happens today, if the version detected is >= JDK
> 9. However, I saw your changes in
> https://github.com/apache/thrift/pull/2606
> And, I think that is nicer, because it enforces JDK 11 for building.
> But it still produces Java 8 compatible binaries.
>
> > 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
>
> I thought the lib/kotlin directory basically served this purpose
> already. Are there other cross-tests? Or are you proposing some other
> move? It's not clear what you're proposing here.
>
> > 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.
>
> I don't see any benefit to doing that at all. There's not really any
> benefit to producing Java 11 byte code from the same Java 8 source
> files as what is in libthrift. This would only matter if there were
> Java 11-specific improvements... and I don't see any interest here in
> maintaining two versions of libthrift, one with Java 8 compatibility
> and one with Java 11-specific changes. The libthrift built to be
> compatible with Java 8 works perfectly fine on Java 11, so there's no
> reason to have a separate artifact for Java 11 only.
>
> >
> > 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 to that. Although it already works that way today, I'll follow your
> PR that is making improvements to how this is done.
>
> --
> Christopher
Re: Dropping Java 8 support?
Posted by Christopher <ct...@apache.org>.
On Thu, May 12, 2022 at 9:05 PM Jiayu Liu <ji...@hey.com.invalid> wrote:
> 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)
This is already what happens today, if the version detected is >= JDK
9. However, I saw your changes in
https://github.com/apache/thrift/pull/2606
And, I think that is nicer, because it enforces JDK 11 for building.
But it still produces Java 8 compatible binaries.
> 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
I thought the lib/kotlin directory basically served this purpose
already. Are there other cross-tests? Or are you proposing some other
move? It's not clear what you're proposing here.
> 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.
I don't see any benefit to doing that at all. There's not really any
benefit to producing Java 11 byte code from the same Java 8 source
files as what is in libthrift. This would only matter if there were
Java 11-specific improvements... and I don't see any interest here in
maintaining two versions of libthrift, one with Java 8 compatibility
and one with Java 11-specific changes. The libthrift built to be
compatible with Java 8 works perfectly fine on Java 11, so there's no
reason to have a separate artifact for Java 11 only.
>
> 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 to that. Although it already works that way today, I'll follow your
PR that is making improvements to how this is done.
--
Christopher
Re: Dropping Java 8 support?
Posted by Jiayu Liu <ji...@hey.com.INVALID>.
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 <yu...@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 <tr...@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
> <yu...@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.
> >
Re: Dropping Java 8 support?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
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 <tr...@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 <yu...@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.
>
Re: Dropping Java 8 support?
Posted by Triton Circonflexe <tr...@kumal.info>.
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 <yu...@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.
Re: Dropping Java 8 support?
Posted by Yuxuan Wang <yu...@reddit.com.INVALID>.
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
>