Quarkus Community Call - 16/12/2025 #51772
cescoffier
started this conversation in
Design Discussions
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
On the 16th of December, we had our continued discussion on Quarkus classloading and the path to modularization.
Here is a short summary. You can find the complete minutes (including the recording) on https://docs.google.com/document/d/1TgFZsuOQo9qZ4CnQII5LHhQVgMC6YsVMs1UJIAJooyM/edit?tab=t.0.
Recap:
The discussion focused on the long-term goal of moving to a modular runtime to replace existing class loading artifacts. David Lloyd and Sanne Grinovero prioritized the implementation of automatic module names for core modules and extensions as the immediate next step, noting that testing in module mode cannot begin until this foundation is laid.
The group addressed the current limitations of the Project Leyden optimizations, noting they currently only work with the app class loader, though extending this to custom loaders remains a goal. David clarified that native images can indeed support custom class loaders at build time, but supporting isolated class loader graphs would require building the module graph strictly at build time.
On the packaging front, there was agreement to create a bootstrap script to help manage the complexity of module paths versus class paths for users. The team also decided to deprecate the "only if" conditionals in build items to simplify the packaging logic and support new targets like modular native images. Finally, David proposed a dedicated "clean room" discussion in March to redesign test class loading to resolve urgent issues with class ordering and thread context loaders.
Beta Was this translation helpful? Give feedback.
All reactions