Hi Brian, Yes, I am familiar with JEP 390 <https://openjdk.org/jeps/390>!
JEP 390 is great for diagnostic warnings, but my main focus is on the *bytecode generation *for third-party libraries. Specifically, I am exploring how maintainers targeting older source versions (e.g., Java 11 or 17) could declare value-ready so that build tooling (or Multi-Release JAR pipelines) can emit actual JEP 401 value class bytecode when targeting a Valhalla-enabled JVM, without bumping the library's baseline Java version. Given that @ValueBased is an internal API, is the OpenJDK vision that external libraries should strictly follow the tip-and-tail model (bumping minimum JDK version), or is there room/guidance for source-level metadata/plugins to bridge legacy source code to Valhalla bytecode? On Sun, Sep 20, 2026 at 10:19 AM Brian Goetz <[email protected]> wrote: > Are you familiar with https://openjdk.org/jeps/390? > > On 9/19/2026 11:10 AM, Anderson Vasconcelos Pires wrote: > > 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> > > <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> > <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 > > >
