RFR: 8344942: Template-Based Testing Framework [v71]

[Emanuel Peter]

On Mon, 2 Jun 2025 13:31:57 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 91 commits:
>> 
>>  - Merge branch 'master' into JDK-8344942-TemplateFramework-v3
>>  - validation tests
>>  - dollar and hashtag parsing validatiaon
>>  - wip refactor parsing dollar and hashtag
>>  - more fixes from Christian
>>  - more improvements
>>  - more suggestions applied
>>  - good practice
>>  - rename template arguments
>>  - more from Christian
>>  - ... and 81 more: https://git.openjdk.org/jdk/compare/90d6ad01...cb7037e7
>
> test/hotspot/jtreg/compiler/lib/template_framework/CodeFrame.java line 92:
> 
>> 90:     /**
>> 91:      * Creates a special frame, which has a {@link #parent} but uses the {@link NameSet}
>> 92:      * from the parent frame, allowing {@link Template#defineName} to persist in the outer
> 
> `defineName` -> `addName`?

Good catch! Left over from a previous refactoring. `javadoc` does not complain about it, because it seems it does not look at anything that is not `public` 🙈

> I have not checked if this is fully possible but it just occurred to me when reviewing this duplicated interface now.

It would require `Name` to be public. As I said above, I'd like to avoid that. We could of course detach `Name.Type` and make it its own interface `NameType`, and make that public. (Just calling it `Type` is a bit too generic, and may lead to name collisions later on).

Having `Name.Type` private and `DataName.Type` and `StructuralName.Type` public means they are separate, and the user cannot use one for the other. Hence, the user cannot confuse them as easily.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24217#discussion_r2122809426
PR Review Comment: https://git.openjdk.org/jdk/pull/24217#discussion_r2122807687