Working Group Proposal: Java 25

[clement escoffier]

Hello,

I just submitted a new working group proposal for Java 25.

The link to the proposal is https://github.com/quarkusio/quarkus/discussions/49696.

I’ve attached a copy of the current proposal below. Please comment on the proposal. If there is no objection, I will kick start the working group on Friday. 

Objective

To enable Quarkus applications to run cleanly across dev/test/production modes on Java 25, with no requirement to adopt Java 25 as a baseline.

The Problem

Java 25 brings new features and platform-level changes (e.g., new JEPs, VM flags, performance tweaks) that may trigger warnings, break behavior, or degrade Quarkus experiences. Dependencies or extensions may also face compatibility challenges. A coordinated effort is needed to identify, fix, document, and optionally leverage these changes.

The Solution

The working group will:

- Attempt to run representative Quarkus applications under Java 25 in dev, test, and production modes.

- Catalog issues, warnings, or incompatibilities in a Wiki or issue tracker.

- Propose and implement fixes or mitigations (or document workarounds).

- Optionally explore beneficial Java 25 features (e.g., Scoped Values, Flexible Constructor Bodies), without requiring their use.

- Identify and remediate or flag problematic Quarkus extensions.

⠀

Definition of Done

- Publish a wiki page detailing issues and resolutions.

- Ensure Quarkus core and its ecosystem can operate cleanly under Java 25 in all modes.

- Integrate any selected Java 25 features in an optional, non-breaking manner.

- Document or fix problematic extensions, offering guidance where needed.

- Communicate results via a blog post or quarkus-dev announcement.

⠀

Scope of Work

In scope:

- Running and diagnosing Quarkus on Java 25.

- Fixing issues in Quarkus core repository and extensions.

- Exploring select Java 25 enhancements.

⠀

Out of scope:

- Mandating Java 25 as the minimum supported runtime.

⠀

Organizing the Work

Communication & Transparency: Use GitHub discussion, project board, and issues. Coordinate via Quarkus Zulip and GitHub.

Points of Contact: Sanne and Guillaume.

Timeline & Milestones: Run tests on Java 25 Candidate Release, document findings before GA (target: before September 16, 2025), so we can guide our users as soon as Java 25 reaches GA.

Clement

[Paul Carter-Brown]

Hi Clement,

We tend to lockstep our product with the latest java release and also
use virtual threads pretty much everywhere we can. We will certainly
help with raising any issues as 25 comes out. We have over 1700
integration tests that cover a large surface area. So will be happy to
help out with real-world experiences.

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CF46DB2C-86D3-4D0B-ABD5-BF32F0EBF9A3%40gmail.com.

[clement escoffier]

Awesome! Thanks Paul!

Clement

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMd%3DrQ9%2Bj%2Bo4i%3DrjYxaWFw883pfD_m-agpqdnLKnBpe%2Br1tYdg%40mail.gmail.com.

[Benjamin Evans]

Just from my own rather limited experiments with 25-ea there is a lot
of stuff that is throwing new warnings when migrating 21 -> 25.

Maven and Maven plugins seem to be particular sources of new grumbles
- so I think keeping a note of the baseline of Quarkus's "grumble-free
dependencies" would be a great idea.

> To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAMd%3DrQ9%2Bj%2Bo4i%3DrjYxaWFw883pfD_m-agpqdnLKnBpe%2Br1tYdg%40mail.gmail.com.
>

[Georgios Andrianakis]

As @David Lloyd has said on some GitHub issues, we need a comprehensive approach for configuring the proper JVM flags that open modules. Requiring users to manually specify them would amount to a terrible developer experience...

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CANSpitzMoiEd_NqWL3NhSYS_jjYDcN4_34Yw3dK9sVWnd-k5Bg%40mail.gmail.com.

--

Georgios Andrianakis

Independent Contractor

[clement escoffier]

Hello,

I kept the “script” idea out of the WG on purpose, as we need to explore what can be done first.

The “script” idea is relatively simple:

- Each extension would be able to produce build items with a specific Java option flag

- when building a container, the build java -jar command will include these flags (passed using run-java.sh options in JVM mode, or in the command line in native mode)

- When building a regular Quarkus app (both JVM and native), we would generate a run-quarkus.sh/bat with the right command

- In dev mode, we would pass the same set to the quarkus-dev command line

I believe we would need that, but let’s first see the number of flags and options we are talking about. 

Clement

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-n8u2z_Kuj1DP0J51yPawYbLfKKhFza2ugxynaJksqMWw%40mail.gmail.com.

[Georgios Andrianakis]

On Wed, Aug 27, 2025 at 9:08 AM clement escoffier <clement....@gmail.com> wrote:

Hello,

I kept the “script” idea out of the WG on purpose, as we need to explore what can be done first.

The “script” idea is relatively simple:

- Each extension would be able to produce build items with a specific Java option flag

- when building a container, the build java -jar command will include these flags (passed using run-java.sh options in JVM mode, or in the command line in native mode)

- When building a regular Quarkus app (both JVM and native), we would generate a run-quarkus.sh/bat with the right command

- In dev mode, we would pass the same set to the quarkus-dev command line

I believe we would need that, but let’s first see the number of flags and options we are talking about. 

Do we really need a script? Isn't it possible to "burn" the flags into the jars manifest?

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/1C540904-867D-4D81-AEBC-146035DCC8C2%40gmail.com.

[David Lloyd]

On Wed, Aug 27, 2025 at 5:25 AM 'Georgios Andrianakis' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

On Wed, Aug 27, 2025 at 9:08 AM clement escoffier <clement....@gmail.com> wrote:

Hello,

I kept the “script” idea out of the WG on purpose, as we need to explore what can be done first.

The “script” idea is relatively simple:

- Each extension would be able to produce build items with a specific Java option flag

- when building a container, the build java -jar command will include these flags (passed using run-java.sh options in JVM mode, or in the command line in native mode)

- When building a regular Quarkus app (both JVM and native), we would generate a run-quarkus.sh/bat with the right command

- In dev mode, we would pass the same set to the quarkus-dev command line

I believe we would need that, but let’s first see the number of flags and options we are talking about. 

Do we really need a script? Isn't it possible to "burn" the flags into the jars manifest?

Only if we launch with `java -jar ...`, which we would not necessarily always want to do. This would require that we launch in non-modular mode.

--

- DML • he/him

[Georgios Andrianakis]

Great point.

But even so, jar mode will likely still be popular so we should support a frictionless experience 

Georgios Andrianakis

Independent Contractor

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CANghgrQ8cQrNGaVjKuZQzmKJZ86V1hS2O9sVbL%3Dgh9JdddhwSQ%40mail.gmail.com.

[David Lloyd]

Yeah, it would have to be left up to the packaging steps to determine how the information is consumed.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DCe5pK5fcgkaY0UpgCgd5CpbiJzyC9eEuS_i1WXOv%3Dcg%40mail.gmail.com.

--

- DML • he/him

[Georgios Andrianakis]

👌🏽

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CANghgrTe8wCKri%2B2PZnJMnvniTNQwT_ejoiS26H-_tu2%3DhKUVA%40mail.gmail.com.

[clement escoffier]

Hey,

The working group has been created. 

You can join the Zulip chat: #dev > WG - Java 25 chat

or follow the (currently empty) board: https://github.com/orgs/quarkusio/projects/59/views/1.

Clement

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-%3DJsXUs4wf5-Cuz3HU3EUgGeob0c9TGBB5txnqr4ASEjw%40mail.gmail.com.