Quarkus Community Call - 02/12/2025 #51373
cescoffier
started this conversation in
Design Discussions
Replies: 1 comment
-
|
Question / suggestion: Could the quarkus community calls be uploaded to the youtube channel? Use case: youtube remembers the timestamp when I stopped watching a video. Allows to go back and continue later on. 1H is a bit long for viewing in one session. :) |
Beta Was this translation helpful? Give feedback.
0 replies
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.
-
Hello,
Yesterday, we had our second public Quarkus community call.
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.
Recap:
Quarkus still has multiple classloader implementations, and David outlined the goal of moving to a single, coherent model that treats classloaders as a structural part of the platform rather than ad hoc fixes. Holly described the recent change where test classes are now loaded directly by the appropriate Quarkus classloader via a facade loader, which improves reliability but exposes IDE/JUnit launch quirks. Sanne reiterated the design choice to avoid dynamic classloading in production, emphasizing fully defined, pre-optimized images for performance, security, and operational predictability. Robert introduced the idea of “intermediate augmentation,” where a base image can be re-augmented with user extensions (for example alternative CDI beans) while still trimming unused extensions. Alexey discussed a provisioning / installer-style tool that takes a base distribution plus a spec of desired extensions and outputs a tailored fast-jar or image, avoiding mutable JARs. There was broad agreement that Jenkins-style runtime plugin installation should instead be modeled as building and testing new images rather than dynamically loading plugins into a running process.
Clement, Sanne, and David covered experiments with Chicory/WASM and sandboxed plugins, where plug-ins would only be allowed to call a constrained, pre-declared API surface.David presented the JPMS roadmap: first produce modularized outputs, then modularize Quarkus itself, mainly to leverage JLink, stronger boundaries, and align with where the JDK is going.
Sanne detailed Leyden’s promising AOT cache optimizations but noted they currently only work with the system classloader, so Quarkus needs future hooks for custom loaders like fast-jar.
Clement closed with a high-level view of Quarkus 4 planning (Vert.x 5, better virtual threads, HTTP/3, new classloading model, etc.) on a long horizon, with no short-term commitments.
Beta Was this translation helpful? Give feedback.
All reactions