<i18n dev> RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v8]

[Jim Laskey]

On Wed, 2 Nov 2022 18:01:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey 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 22 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Add @SafeVarargs declarations
>>  - Move template bootstrap
>>  - Requested changes #2
>>  - Requested changes
>>  - Remove .orig file
>>  - Update TemplateRuntime::combine
>>  - Move StringConcatItem to FormatConcatItem
>>  - Tabs to spaces
>>  - Force processor before template string expression
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/882a8efa...6cea084b
>
> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 175:
> 
>> 173:             int size = st.values().size();
>> 174:             for (int index = 0; index < size; index++) {
>> 175:                 result.add(MethodHandles.insertArguments(GET_VALUE_MH, 0, index));
> 
> The returned method handle takes a `StringTemplate` as an argument, but doesn't guard against the fact that a different string template instance can be passed than the one used here, which can lead to errors when invoking the method handle (e.g. out of bounds access, or cast failures when the value types are different).
> 
> I was gonna suggest using `List::get` as a method handle instead, and then binding the `values()` list and the index to that. That would drop the `StringTemplate` param, which I suppose is important for `javac` generated code? Could add a `dropArguments` for that, but then the argument would always be ignored.
> 
> Maybe alternatively, the `getValue` method could do a check that the `StringTemplate` instance passed to it is the same instance as the one used here.
> 
> I don't know...

Pulled method

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

PR: https://git.openjdk.org/jdk/pull/10889