Hi Oleksandr, Thanks for continuing to lead this effort. I'm fully in support of dropping Java 11 and adding support for Java 21 and 25 in the master branch (TP4).
As for the 3.8-dev situation, I think your proposal for "partial java 25 support" makes sense. I've yet to complete a full review of your PR, but I support the idea of a non-breaking update which will allow most/some users to upgrade to Java 25. I'm still a bit undecided on the communication side of this change though, I want to be careful we don't mislead anyone or set the wrong expectations. I think it's ok to say that 3.8.2 will fully support Java 11 and 17, with partial support (excluding gremlin-spark) for Java 21 and 25. If there are any other caveats involved in Java 25 usage in 3.8.2, then we should perhaps downgrade the messaging to something like "experimental support". I'm happy to move forward with the 2 PRs. I'll do my best to complete my reviews of them shortly. As I mentioned in another thread recently, I think we're due for the next set of releases soon. Unless any major blockers arise, I think it would be nice to see both of these PRs land before calling code freeze. Thanks, Cole On 2026/07/01 11:30:09 Oleksandr Porunov wrote: > Hi everyone, > > I’d like to kick off a discussion regarding our Java version compatibility, > specifically around dropping Java 11 support to pave the way for Java 25. > We recently started this conversation in Discord and wanted to bring it to > the dev list to get broader input, especially from graph providers. > The Background & The Problem > > We are looking to add Java 25 support to TinkerPop. However, we've hit a > blocker with gremlin-spark. The newer versions of Spark required to support > Java 25 have dropped support for Java 11 (they require a minimum of Java > 17). This means we cannot support both Java 11 and Java 25 simultaneously > in the gremlin-spark module. > Proposal 1: Drop Java 11 in master (TinkerPop 4) > > My primary proposal is to drop Java 11 support entirely in the master branch > (TinkerPop 4) and move our baseline to at least Java 17. > > *The Benefits:* Beyond simply keeping our dependencies up to date, moving > to modern Java LTS versions (like 21 and 25) gives us access to Virtual > Threads. This is a massive benefit for graph providers, allowing for heavy > resource optimization without requiring a complex async engine > implementation on the TinkerPop side. Providers can continue to process > steps synchronously but with a drastically reduced resource footprint. > > *(PR for full Java 25 support targeting > master: https://github.com/apache/tinkerpop/pull/3489 > <https://github.com/apache/tinkerpop/pull/3489>)* > Proposal 2: Partial Java 25 Support in 3.8-dev > > Because we need to respect semantic versioning, dropping Java 11 in the > 3.8.x line isn't feasible. As an intermediate solution, I propose we > upgrade all modules in 3.8-dev to be compatible with Java 25 *except* for > gremlin-spark. > > This "middle ground" approach delivers real value to the majority of users > and providers who want to run modern Java, though we will need to be > careful with our documentation and messaging to ensure users understand why > gremlin-spark is excluded. > > *(PR for partial Java 25 support targeting > 3.8-dev: https://github.com/apache/tinkerpop/pull/3488 > <https://github.com/apache/tinkerpop/pull/3488>)* > Alternative Option > > If there is a strong need to maintain Java 11 in TP4 for some reason, one > highly complex alternative would be a secondary compilation phase that > patches and publishes separate artifacts with a -java25 suffix. This isn't > ideal and could cause user confusion, so my strong preference is to simply > drop Java 11. > Questions for the Community > > 1. > > *Providers:* Is anyone still strictly relying on Java 11 for future > deployments, or are you comfortable with a Java 17 minimum for TinkerPop 4? > 2. > > *Everyone:* What are your thoughts on the "partial" Java 25 support > strategy for the 3.8.x releases? > > Looking forward to hearing your thoughts! > > Best regards, > > Oleksandr Porunov >
