Quarkus Community Call - 04/11/2025

[cescoffier]

Hello,

Today we had our first public Quarkus community call. Thank you to the 45 attendees!
Here is a short summary. You can find the complete minutes (including the recording) on https://docs.google.com/document/d/1TgFZsuOQo9qZ4CnQII5LHhQVgMC6YsVMs1UJIAJooyM/edit?usp=sharing.

Introduction

@cescoffier opened the first public Quarkus Community Call, now planned to run bi-weekly.
He introduced the Quarkus Calendar Repository and shared public links for viewing or subscribing to upcoming calls.
The session featured Guillaume Smet on Quarkus for Large Applications and Georgios Andrianakis with a GraalVM Summit recap.

Quarkus for Large Applications (@gsmet )

Originating from a comparison between large Spring and Quarkus apps, the study defined “large” as 1000+ CDI beans or classes.
Results showed Quarkus apps start faster and use less memory, but build slower, largely due to bytecode enhancement and proxy generation.
Optimizations between Quarkus 3.25 and 3.28 halved build time for a 4,000-element app through Arc, Jandex, and Hibernate improvements.
At 5,000 elements, a ClassTooLargeException appeared in Arc—expected to be resolved by Gizmo 2.
Guillaume emphasized removing arbitrary limits to better support large monolith migrations and planned further profiling and documentation work.

GraalVM Summit Recap (@geoand )

The summit followed GraalVM’s decoupling from OpenJDK.
Two main projects were presented:
• Project Terminus: modularizes native-image by treating the JDK as a pluggable build component.
• Project Crema: introduces a hybrid model between JVM and native execution, enabling scripting and dynamic features.

Day 2 focused on polyglot capabilities (Python, JS, WASM), with Oracle aiming to make GraalVM the best Python interpreter.
These innovations are 18+ months away, but Quarkus remains committed to native-image integration and close collaboration with the GraalVM team.

[dmlloyd]

I'm quite interested in how the different packaging types compare when the application is large, specifically relating to class loading and startup time/time to first request.

[cescoffier]

\CC @gsmet

[mkouba]

At 5,000 elements, a ClassTooLargeException appeared in Arc—expected to be resolved by Gizmo 2.

For the record, 5000 is not the current hard limit. It depends on many factors, including the complexity of the class hierarchy and the dependency graph, the number of intercepted beans, the number of declared observers, etc.

For example, in the arc-crazybeans app each generated bean class also declares a producer method (another bean), an observer and four intercepted methods. As a result, 1000 generated bean classes means 2000 beans, 1000 observer methods, and 4000 intercepted methods. However, there are no dependencies between the generated beans and the class hierarchy is flat. You'd get a different result if there are just a few observers, the class hierarchy and the dependency graph is complex.