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

[Emanuel Peter]

On Fri, 30 May 2025 06:32:54 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8344942-TemplateFramework-v3' of https://github.com/eme64/jdk into JDK-8344942-TemplateFramework-v3
>>  - move verification
>
> test/hotspot/jtreg/compiler/lib/template_framework/Template.java line 174:
> 
>> 172:  * <p>
>> 173:  * The dollar and hashtag names must have at least one character. The first character must be a letter
>> 174:  * or underscore (i.e. {@code a-zA-Z_}), the other characters can also be digits (i.e. {@code a-zA-Z0-9_}).
> 
> This does not seem to be enforced:
> 
>         var testTemplate = Template.make(() -> body(
>             """
>             public class Foo {
>                 public static void main() {
>                     int $1var = 34;
>                 }
>             }
>             """
>         ));
>         System.out.println(testTemplate.render());
> 
> Results in:
> 
> public class Foo {
>     public static void main() {
>         int $1var = 34;
>     }
> }
> 
> which compiles fine. I can also change it to `$$var` which renders to `$var_1` which also compiles fine.

@chhagedorn Gosh, this is actually not so simple, to write a good regex here that also parses the "bad" cases.
Consider this:
`#{abc}` Is now ambiguous: should we parse `#` as an empty name, and `{abc}` as unrelated? Or is it a bracketed name `abc`?

I could first parse all the bracket patterns, and then the non-bracket patterns. But what if someone does a bracket replacement, and inserts a non-bracket pattern? Then we might end up re-parsing the inserted String, and try to replace there again. What a mess!

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

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