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
shado
On Thu, May 12, 2022 at 9:05 PM Jiayu Liu 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 c
Jimexist opened a new pull request, #2606:
URL: https://github.com/apache/thrift/pull/2606
use gradle toolchain to specify Java 11 with --release 8
- [ ] Did you create an [Apache
Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket? (not
required for
Liu Jiayu created THRIFT-5584:
-
Summary: Use gradle toolchain to specify build time Java version
Key: THRIFT-5584
URL: https://issues.apache.org/jira/browse/THRIFT-5584
Project: Thrift
Issue Type
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 g
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
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 r
fishy merged PR #2605:
URL: https://github.com/apache/thrift/pull/2605
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@thrift.apache.org
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 compati
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 wrote:
> Hi dev@thrift,
>
> I've been working on the Java generator and libr
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
11 matches
Mail list logo
