On Wed, 8 Jul 2026 22:24:18 GMT, Chen Liang <[email protected]> wrote:
> This is some extremely basic overview about value class migrations. > > 1. Build: I intentionally skipped the streamlined build system installed by > David Beaumont. Instead, I stressed the custom handling used by Value Objects > JEP. (The "Preview Classes in Interim `javac`" section might go to general > documentation later.) > > 2. Testing: I started from the motivations/goals and describe how those goals > are accomplished. > 3. Wrapper class caches: Some simple overview. > > There are definitely more topics to cover; feel free to raise. > > Paging @jddarcy and @viktorklang-ora for proofreading. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). And once the text of the note if finalized, links to it in `//` comments should be added to the wrapper classes and the `java.time` classes. doc/value-class-preview.md line 8: > 6: to value classes. This means that when preview features are enabled, a > different > 7: classpath is available to Java programs. To accomplish this, the JDK has a > 8: custom build and deployment process to allow access to different > classpaths. I think this intro should explicit words to the effect of "there are separate class files for migrated value classes with preview enabled and with preview enabled. First new source files are generated from the original files to be migrated and then these new source files are compiled into separate class files are put into a distinct class path, etc." (The salient point here for core libs maintainers include there is a new source-based transform and, as explained later in the note, understanding the limited functionality of the transform. Other technically possible ways to do this transform would include class file re-writing, possibly at startup, etc.) doc/value-class-preview.md line 27: > 25: source files where these occurrences are replaced by `value class` and > 26: `value record`, respectively. > 27: So, with the current system, consequently, any needed testing of "is preview enabled" must be done at runtime rather than via a compile-time macro? (The other little code gen systems used in the JDK have a more expressive set of primitives. In my estimation, the simple system here is good for the purpose it is being used for, but it is helpful to document it here.) ------------- PR Comment: https://git.openjdk.org/valhalla/pull/2633#issuecomment-4921816516 PR Review Comment: https://git.openjdk.org/valhalla/pull/2633#discussion_r3548975406 PR Review Comment: https://git.openjdk.org/valhalla/pull/2633#discussion_r3548986281
