You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Backport of the JDK Classfile API (java.lang.classfile) from OpenJDK to Java 17. Transitive dependency via Quarkus quarkus-core-deployment through gizmo2, used for bytecode generation at build/augmentation time.
Distribution and integration model
CNCF-Distributed: The CNCF project will distribute the dependency or the resulting combined artifacts to users.
User-Fetched Dependency: The CNCF project code will cause the user's system to automatically retrieve the dependency from an upstream source at build, install, or runtime.
System Component: The CNCF project expects that the dependency will either already be present on the user's system or will be installed independently by the user.
Not Distributed + Not Needed by End User (Internal Project Tooling): ALL of the following are true:
Please explain
It is a dependency required only during the build, however Keycloak application can be reaugmented, therefore for users who are using Keycloak images, they need to be present in the Keycloak container as well.
Modification status
Modified Upstream: The CNCF project will patch, alter, or otherwise modify the source code of the dependency and contribute upstream.
Modified Downstream: The CNCF project will patch, alter, or otherwise modify the source code of the dependency and maintain a downstream fork or local copy.
Unmodified: The CNCF project will use the dependency exactly as provided by the upstream maintainers without any changes to its source code.
Please explain
Quarkus will keep using the OpenJDK backport as it is more stable than depending on the JDK runtime directly.
Structural separation
Separated Component: The dependency's code will either be (a) kept in a distinct directory or module clearly separated from CNCF project code, or (b) retrieved at build/installation time from a third-party repository and never stored in the CNCF project repository.
Intermingled Code: The dependency's code will be "mixed in" with CNCF source files, copied into existing project files, or will otherwise lose its distinct directory/module boundary.
Please explain
It is a transitive Maven dependency. We do not modify this code, only use it as it is on a class-path during the build.
Communication mechanism
Static Linking: The dependency and the CNCF project code will be combined into a single binary or similar type of artifact during the build process.
Dynamic Linking: The CNCF project code will interact with the dependency by loading it into the shared address space (memory) at run-time. This includes traditional shared objects compiled into a separate binary, as well as runtime module loading in interpreted or JIT-compiled languages.
Separate Process: The dependency and the CNCF project code will run as distinct executables and communicate via Inter-Process Communication (e.g., pipes, sockets, or shared files)
Network Interaction: The dependency and the CNCF project code will be logically and physically separated by a network boundary, with the CNCF project's code acting as a client or consumer of the remote service and interacting with the dependency exclusively via standardized network protocols.
Please explain
Classes from this dependency are loaded into JVM metaspace at augmentation time.
Data exchange
Tightly Coupled: The upstream dependency and CNCF project code will exchange complex internal data structures such as shared pointers, class instances, or private memory offsets that require extensive knowledge of the other component's internal memory layout.
Arms-Length Only: The communication between the dependency and the CNCF project code will be limited to standard serialized data (e.g., JSON, XML, or Protobuf) where data is "flattened" for transport and neither component accesses the other's internal memory structures.
Please explain
Keycloak uses Quarkus and Quarkus uses Gizmo2, which calls these classes directly via Java method invocations.
For which CNCF project are you requesting exceptions?
Keycloak
Are you an official maintainer of this project?
No
List of components requiring an exception
Distribution and integration model
Please explain
It is a dependency required only during the build, however Keycloak application can be reaugmented, therefore for users who are using Keycloak images, they need to be present in the Keycloak container as well.
Modification status
Please explain
Quarkus will keep using the OpenJDK backport as it is more stable than depending on the JDK runtime directly.
Structural separation
Please explain
It is a transitive Maven dependency. We do not modify this code, only use it as it is on a class-path during the build.
Communication mechanism
Please explain
Classes from this dependency are loaded into JVM metaspace at augmentation time.
Data exchange
Please explain
Keycloak uses Quarkus and Quarkus uses Gizmo2, which calls these classes directly via Java method invocations.
Please explain
jdk-classfile-backportstarting from 26.4.x releases.