Hi Valhalla team, Before diving into the details, I want to clarify right away that this is not a proposal to backport the JEP 401 implementation or JVM-level value classes to older Java versions. Instead of a true semantic backport, the goal is to discuss mechanisms that allow current and legacy codebases (especially foundational libraries) to explicitly declare their "value-ready" today. This would enable automated tooling—such as compiler plugins or build tools—to easily recompile these classes that meet the requirements of value classes into true value classes (or generate Multi-Release JARs) when running on or targeting a Valhalla-enabled JVM. As we know, the ecosystem transition is often a major bottleneck. While internal OpenJDK tests already use a similar approach with ValueClassPlugin <https://github.com/openjdk/jdk/blob/master/test/jtreg_value_class_plugin/plugin/jdk/test/valueclass/ValueClassPlugin.java> .java using @AsValueClass to transform annotated classes during the PARSE phase. I want to emphasize that an annotation is just one potential mechanism. The core idea is establishing a standardized way to opt-in or list candidate classes, whether that happens through annotations, configuration files, package-level descriptors, or external metadata. Rémi Forax also explored a related direction some time ago with Einherjar <https://github.com/forax/einherjar>. For this approach to be truly successful and reach the maximum number of developers, it is crucial that this preparation strategy is driven, promoted by the Java Platform itself. Rather than leaving it entirely as a fragmented ecosystem effort. Having the Java team guide this model would give library maintainers a predictable, standardized framework to start preparing their codebases early to use value classes when running on JVM with value class support. I would love to open a discussion on the best way to design and deliver such a preparation mechanism to the community:
- What is the best mechanism for metadata? Should we use source-level annotations, a standardized configuration file listing eligible classes/packages, or perhaps external descriptors? If annotations are considered, where should they live (e.g., an official migration/incubation module or a community standard like JSpecify)? - Tooling & Multi-Release JARs: How do you see the role of build tools here? For instance, a Java Maven/Gradle plugin could ingest these candidate lists and automatically emit Multi-Release JARs containing the value class bytecode alongside legacy identity class bytecode. - Validation Concerns: How can we safely encourage library authors to declare value-intent in older Java versions where the local compiler cannot strictly enforce Valhalla's constraints (e.g., lack of identity, final fields)? Could an external linter or a lightweight verification tool bridge this gap? Project Valhalla has the potential to significantly improve memory footprint and performance for appropriate workloads.. However, history shows that foundational libraries take a long time to adopt new language versions because they must maintain backward compatibility. By actively promoting a standard way to express value-readiness early on, the Java platform can drastically accelerate ecosystem-wide adoption the moment Valhalla officially releases. Looking forward to your feedback and insights on how we might best approach this. In my personal view, the most simple approach would be a Maven/Gradle build plugin driven by a configuration list generating a Multi Release jar. Best regards, Anderson
