On Fri, 6 Mar 2026 12:08:35 GMT, David Beaumont <[email protected]> wrote:
>> 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. As Jan says, there's a question of whether this is the right mechanism at all. I reached for it because the value type annotations exist and must already be correct; they are the canonical expression of intent of something "being a value type candidate". And since annotations are reliably processed with annotation processors (and also, since the Makefile mechanisms are still deeply unfamiliar to me) I decided to try doing this with what I an already familiar with. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2180#discussion_r2895463097
