RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7]
Jim Laskey
jlaskey at openjdk.org
Thu Nov 3 14:27:50 UTC 2022
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
More information about the compiler-dev
mailing list