On Tue, 21 Apr 2026 12:04:15 GMT, David Beaumont <[email protected]> wrote:
>> Adds a new AnnotationProcessor to read the @MigratedValueClass on >> prospective value classes and generate the equivalent source file with the >> 'value' keyword at each annotated class declaration. >> >> This adds new PROCESSOR_PATH variable to the compilation macro and use it >> for annotation processing. >> This also requires moving the plugin discovery path to the new variable (was >> in classpath before) because the addition of a '--processor-path' flag >> disables using the classpath for plugin discovery. >> >> For now this is all limited to `java.base` but that's expandable later >> easily. There was an issue just enabling it for all modules however (esp. >> `jdk.incubator` which might be special). >> >> While there is currently no specific unit test for this code, if it were to >> fail to generate the correct value classes, a lot of other downstream tests >> would fail. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > David Beaumont has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 19 additional > commits since the last revision: > > - Merge branch 'lworld' into jdk_8377101_gensrc/squashed > - Make AP swallow all unprocessed annotations > - Remove unwanted lint warning suppression > - Merge branch 'lworld' into jdk_8377101_gensrc/squashed > - Finally working > - Latest changes (inc. feecback). > > * feedback updates and tidying > * better compile macro call - still not working > - [[UNDO FORMATTING IN SQUASH BRANCH]] > - [[AUTOMATIC FORMATTING]] > - better but still not working > - Simpler temp directory > - ... and 9 more: > https://git.openjdk.org/valhalla/compare/456465a7...6b9608a8 make/jdk/src/classes/build/tools/valhalla/valuetypes/GenValueClasses.java line 128: > 126: Optional<? extends TypeElement> valueClassAnnotation = > 127: getAnnotation(annotations, > MIGRATED_VALUE_CLASS_ANNOTATION); > 128: if (valueClassAnnotation.isPresent()) { I would expect a call to RoundEnvironment.getElementsAnnotatedWith() to be used in this method. Is there a reason for avoiding that? If you need to operate on the _files_ containing the annotated types, you could use Elements.getFileObjectOf to create a set of them. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2180#discussion_r3120276696
