On Fri, 6 Mar 2026 07:55:56 GMT, Jan Lahoda <[email protected]> wrote:
>>> After talking with Jan, this seemed the better option. What would the Filer >>> API have simplified here? >> >> After some further consideration, I could give better guidance if I >> understood more about the overall architecture about how the annotation >> processor was being used in the build process and how the Valhalla build >> would be sequenced with this change. >> >> I have not attempted to research how the Valhalla build differs from a >> mainline build, but I'm generally aware there is some kind of >> post-processing of classes in java.base to make them value classes in the >> Valhalla images output. >> >> I think two basic approaches to running an annotation processor to aid the >> post processing would be: >> >> 1) As an integrated part of the "base build", have the annotation processor >> run and generate the new source files in the chosen directory. (Is these >> were completely new files and new not meant to replace existing files in the >> output, the compilation of the new files could be handled as part of the >> built-in annotation processing compilation machinery). >> >> 2) As a post-pass after the base build, scan over the source (or class >> files) in question and find the annotated classes to have replacements be >> generated. >> >> For something closer to 1) the Filer has a few facilities to do extra >> checking and some infrastructure for concepts like the SOURCE_OUTPUT >> location. > > My understanding (possibly wrong) here was and is that the goal here is to > take the existing primary (non-preview) source for e.g. `java.lang.Byte`, and > produce a new source for the same class that adds the `value` keyword. This > new source is then compiled in a different/separate compilation. So that > there are two separate classfiles produced, one for the original source, and > one for the newly generated source. Filer didn't seem like a very good fit > for this task. > > In a sense, the annotation processing here is used mostly as a vehicle to get > the source code model. Of course, there can be a question whether AP is the > right way to do it - we could simply run a Java-based generation task in the > Makefiles, like e.g. here: https://github.com/openjdk/jdk/pull/30072 It's worth noting here that this mechanism is likely to be one of many which eventually gets used to create and manage preview classes. 1. Value classes will eventually be in mainline, and the migration of things like `java.lang.Integer` will be complete. These are no longer "preview classes", they're just normal value classes in normal directories. 2. However, other existing classes, perhaps in other modules, may want to be temporarily previewed as value classes in releases after this. 3. But eventually we'll have got through all the migrations we care about as regards value classes. 4. However ... as regards preview mode, value classes are not the only fruit. I fully expect us to eventually need separate source directories for code which is not value class related, but appears in preview mode. 5. This could be re-writes of existing classes, or new code, or a mix of both. So this PR is about (1) and (2). It's a mechanism to easily allow existing classes to be auto-magically migrated to value types when `--enable-preview` is used. Eventually (years hence) we expect to no longer need it because all existing value classes are migrated and new value classes are just written normally and available by default. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2180#discussion_r2895444880
