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

[Jim Laskey]

On Wed, 2 Nov 2022 17:04:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @SafeVarargs declarations
>
> src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 74:
> 
>> 72: 
>> 73:     /**
>> 74:      * Static final processor.
> 
> Suggestion:
> 
>      * final processor.

"The static final processor that triggered the BSM generation." - Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 103:
> 
>> 101:  * // check or manipulate the fragments and/or values
>> 102:  * ...
>> 103:  * String result = StringTemplate.interpolate(fragments, values);;
> 
> Suggestion:
> 
>  * String result = StringTemplate.interpolate(fragments, values);

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 117:
> 
>> 115:  */
>> 116: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 117: public interface StringTemplate {
> 
> What is the reason for having this open to extension? Rather than just being a final class or sealed interface?
> 
> (I think it is so that implementations can provide a more efficient layout rather than using Lists?)

Generally yes, specializations of the template. Another possibility is other languages can map their template implementations.

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 246:
> 
>> 244:         Objects.requireNonNull(stringTemplate, "stringTemplate should not be null");
>> 245:         return Objects.hashCode(stringTemplate.fragments()) ^
>> 246:                Objects.hashCode(stringTemplate.values());
> 
> Could also (which is also `null` safe):
> Suggestion:
> 
>         return Objects.hash(stringTemplate.fragments(), stringTemplate.values());

Changing

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

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