Everyone interested should test running the java17 branch on your servers.
I believe the biggest priorities are ensuring stability (there was a mention of instability in Moqui with more recent java version) and making it clear and easy that --add-opens=java.base/java.lang=ALL-UNNAMED is needed in documentation, release notes, etc.
I’m currently running java 17 in production across all my production deployments, but haven’t tested 21 at all. I don’t recommend running the java 17 branch in production for clients / real customers until it’s more polished though.
Alright noted. I think perhaps not only should 17 be the default, but also the “minimal”.
The big win if we enable / default 21 is virtual threads. This is a game changer in terms of performance, specifically on parallel work that is not CPU bound (I/O). Heck we can probably utilize this in the framework itself.
Anyway, I’ll start by at least making it run on 17 and see if I face any issues. We’ll take it from there.
I believe that we’re going to continue supporting java 11 for a long time. What would be the benefit of requiring at least java 17?
Virtual threads look great actually.
Jetty 12 supports them Jetty 12 – Virtual Threads Support – Webtide. If the virtual threading is much faster, and there aren’t other problems, we could default to java 21. We would need a proof of concept for how much faster it really is though.