Hello, Note that these two items below are different: 1. Make sure your program runs against a newer version of your dependency. 2. Update your program to a new version, making use of new features in new versions of your dependency.
The goal of Value Objects feature, during its preview, is to make sure programs can accomplish #1 against a Java runtime 28 and above with preview features enabled. Libraries can try to accomplish #2 because value objects is a useful feature; however, for such feature addition, we recommend following the tip-and-tail release model as described in https://openjdk.org/jeps/14 where all the new library features making use of Java's value objects feature should not be backported to older releases. The JDK's AsValueClass is an unfortunate compromise because we want to keep running our tests with preview features DISABLED, where value objects feature is disabled; otherwise, we would just mark the tests as enabling preview features. Libraries following the tip and tail model do not have such issues. TLDR: Don't try to make your library work for all Java versions. If you want a new Java feature, bump your minimum Java version; don't backport features to older release trains. Chen Liang ________________________________ From: Anderson Vasconcelos Pires <[email protected]> Sent: Saturday, September 19, 2026 10:10 AM To: valhalla-dev <[email protected]> Subject: [External] : "Backport" JEP 401: Value Objects 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
