Jeremy Grelle (Jun 11 2026 at 14:58): Jeremy Grelle (Jun 11 2026 at 14:58):I am curious about the reasoning behind continuing to use Java 11 as the baseline supported version in Endive, and I figure now would be the time to bring it up before there is an official 1.0 release.
I bring this up partially for selfish reasons, as I've gotten quite used to being able to take advantage of Java 17 features in other open source work I've done in the last few years. :slight_smile: I've found it to result in significantly cleaner and less verbose code when working on things such as protocols and parsers.
It's obviously not critical if there is a strong justification for keeping Java 11 support...but I feel like Java 17 is a pretty common minimum baseline for a large number of Java open source projects. The transition from Chicory to Endive seems like a prime time to consider whether a bump in Java version is justified.
andreaTP (Jun 11 2026 at 16:27):Thanks for bringing this up, I think it deserves a dive in:
Those are the less profound reasons, the core of the discussion is around target usage:
we do want to enable enterprises(banks, insurances, etc.) to integrate Wasm in their legacy applications without effort.
If, adopting Endive, requires a major version bump of the Java version that's going to be a very hard sell.
Often, regulated environments, are constrained in not upgrading, but we do want to meet possible users where they are, making it compelling to adopt the technology with minimal effort.
To an extreme, I'd love to see a future where extending existing functionality of a legacy Java app is easier to be done in, let say, Rust, other than Java itself.
This is achievable only if we keep going with a very large compatibility matrix, and, so far, seemed the right compromise.
andreaTP (Jun 11 2026 at 16:32):All of that said, I feel the most compelling bump, and I belive is too early, would be to target Java 25 as it brings significant advancement that will significantly improve the codebase:
andreaTP (Jun 11 2026 at 17:54):sorry for the long write-up, hope it makes sense, happy to hear feedback!
Jeremy Grelle (Jun 11 2026 at 18:50):That all makes sense, thanks for the context!
I totally understand the desire to make adoption easy for more conservative enterprises. Spring has historically been on the conservative side when it comes to minimum Java version, so I have a fair bit of experience with that mindset. I can't help but note that their baseline since Spring 6 which was released in 2022 is Java 17, but it is a bit different in that they continued to backport fixes to Spring 5 for some time after that.
Considering it from this perspective, I can see how sticking with Java 11 makes sense. For any more conservative organizations currently using Chicory, it is compelling to make the switch to Endive as frictionless as possible. Updating the baseline in a future major version could be more feasible.
I agree that Java 25 would be that much more beneficial. I can foresee wanting to make use of virtual threads when getting to implementation of the async features of the Component Model, but there's no reason that a fallback to traditional threads couldn't also be provided.
andreaTP (Jun 11 2026 at 20:28):I can't help but note that their baseline since Spring 6 which was released in 2022 is Java 17
Usually, interpreter/compiler projects like endive do not need that much features as opposed to a full fledged framework like Spring or Quarkus.
What I mean is that the Java version is less relevant/impacting in endive.
andreaTP (Jun 11 2026 at 20:29):Updating the baseline in a future major version could be more feasible.
Totally agree, we provide continuity first and we re-evaluate later, totally open to it
andreaTP (Jun 11 2026 at 20:31):I agree that Java 25 would be that much more beneficial.
Yeah, baseline on Java 25 would be really great, looking forward to it when time comes!
Last updated: Jul 29 2026 at 05:03 UTC