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
