StringTemplates name changes

[Brian Goetz]

Was going by

_Old_ 	_New_
java.lang.template.Carriers* 	java.lang.runtime.Carriers*
java.lang.template.ReferencedKeyMap* 	java.lang.runtime.ReferencedKeyMap*
java.lang.template.ReferenceKey* 	java.lang.runtime.ReferenceKey*
java.lang.template.StringTemplateImpl* 
java.lang.runtime.StringTemplateImpl*
java.lang.template.StringTemplateImplFactory* 
java.lang.runtime.StringTemplateImplFactory*
java.lang.runtime.TemplateRuntime 	java.lang.runtime.TemplateRuntime
java.lang.template.TemplateSupport* 	java.lang.runtime.TemplateSupport
java.lang.template.StringTemplate 	java.lang.StringTemplate
java.lang.template.ValidatingProcessor 	java.lang.StringTemplate.Processor
java.lang.template.ProcessorLinkage 
java.lang.StringTemplate.Processor.Linkage
java.lang.template.TemplateProcessor 
java.lang.StringTemplate.SimpleProcessor
java.lang.template.StringProcessor 
java.lang.StringTemplate.StringProcessor



which didn't flag TemplateSupport as package-private.  If it gets a 
star, great.


On 3/27/2023 10:46 AM, Jim Laskey wrote:
> TemplateSupport is used internally in java.lang.runtime and is package 
> private. Nothing to see there.
>
>> On Mar 27, 2023, at 11:18 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> Nice.
>>
>> So that means java.lang additions are limited to StringTemplate (with 
>> nested Processor), and public jl.runtime limited to 
>> Template{Runtime,Support}.
>>
>> In the spirit of "nothing left to take away", who are the methods in 
>> TemplateSupport used by?  Authors of processors?  There's not too 
>> much here -- creation, interpolation, combination.  Would these make 
>> sense as static helper methods on STringTemplate?  They'd be more 
>> discoverable there.
>>
>>
>> On 3/27/2023 9:07 AM, Jim Laskey wrote:
>>>
>>> After the string template interface name changes, i.e., 
>>> |TemplateProcessor| becoming |Processor|, the rationale for the 
>>> existence of |SimpleProcessor |and |StringProcessor| has lessened to 
>>> the point where they should be dropped.
>>>
>>> |SimpleProcessor| owed its existence to the long-winded name 
>>> |TemplateProcessor| and that ugly second parameter, |E|, in 
>>> |Processor<R, E>| (in a many of cases |E| will be the unchecked 
>>> |RuntimeException|). |StringProcessor| existed because most template 
>>> processors will produce strings.
>>>
>>> |TemplateProcessor<JSONObject, RuntimeException> JSON = st-> new 
>>> JSONObject(st.interpolate()); TemplateProcessor<String, 
>>> RuntimeException> INTER = StringTemplate::interpolate;|
>>>
>>> vs.
>>>
>>> |SimpleProcessor<JSONObject> JSON = st-> new 
>>> JSONObject(st.interpolate()); StringProcessor INTER = 
>>> StringTemplate::interpolate;|
>>>
>>> It was thought that having the friendlier interfaces would provide 
>>> clarity, hide |RuntimeException| and simplify explanation. The 
>>> reality is that most developers will define template processors 
>>> using full class declarations. Furthermore, developers will learn to 
>>> use |RuntimeException| regularly due to the abundance of template 
>>> processor examples.
>>>
>>> |public class InterpolateProcessor implements Processor<String, 
>>> RuntimeException> { @Override public String process(StringTemplate 
>>> st) { return st.interpolate(); } } SimpleProcessor<String> INTER = 
>>> new InterpolateProcessor(); |
>>>
>>> Even after |SimpleProcessor| and |StringProcessor| go away, 
>>> developers can still use the functional interface shorthand.
>>>
>>> |Processor<JSONObject, RuntimeException> JSON = st-> new 
>>> JSONObject(st.interpolate()); Processor<String, RuntimeException> 
>>> INTER = StringTemplate::interpolate;|
>>>
>>> And, a new factory method, |Processor.of|, will be added for fans of 
>>> |var|.
>>>
>>> |var JSON = Processor.of(st-> new JSONObject(st.interpolate())); var 
>>> INTER = Processor.of(StringTemplate::interpolate);|
>>>
>>> For those developers that like the notion of |SimpleProcessor| and 
>>> |StringProcessor|, these interfaces can be trivially defined per 
>>> project;
>>>
>>> |@FunctionalInterface public interface SimpleProcessor<R> extends 
>>> Processor<R, RuntimeException> {} @FunctionalInterface public 
>>> interface StringProcessor extends SimpleProcessor<String> {}|
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Mar 17, 2023, at 10:24 AM, Jim Laskey <james.laskey at oracle.com> 
>>>> wrote:
>>>>
>>>> This is a  heads up about some name changes coming to the string 
>>>> template feature with the intent of eliminating the 
>>>> “java.lang.template” package along with clarifying the processor 
>>>> hierarchy,
>>>>
>>>> _Old_ 	_New_
>>>> java.lang.template.Carriers* 	java.lang.runtime.Carriers*
>>>> java.lang.template.ReferencedKeyMap* 
>>>> java.lang.runtime.ReferencedKeyMap*
>>>> java.lang.template.ReferenceKey* 	java.lang.runtime.ReferenceKey*
>>>> java.lang.template.StringTemplateImpl* 
>>>> java.lang.runtime.StringTemplateImpl*
>>>> java.lang.template.StringTemplateImplFactory* 
>>>> java.lang.runtime.StringTemplateImplFactory*
>>>> java.lang.runtime.TemplateRuntime 	java.lang.runtime.TemplateRuntime
>>>> java.lang.template.TemplateSupport* 	java.lang.runtime.TemplateSupport
>>>> java.lang.template.StringTemplate 	java.lang.StringTemplate
>>>> java.lang.template.ValidatingProcessor 
>>>> java.lang.StringTemplate.Processor
>>>> java.lang.template.ProcessorLinkage 
>>>> java.lang.StringTemplate.Processor.Linkage
>>>> java.lang.template.TemplateProcessor 
>>>> java.lang.StringTemplate.SimpleProcessor
>>>> java.lang.template.StringProcessor 
>>>> java.lang.StringTemplate.StringProcessor
>>>>
>>>>
>>>> (*) - package private
>>>>
>>>>
>>>> The new processor hierarchy will be;
>>>>
>>>> interface Processor<R, E>
>>>> interface SimpleProcessor<R> extends Processor<R, RuntimeException>
>>>> interface StringProcessor extends SimpleProcessor<String>
>>>>
>>>> It will take me a few days to update the JEP, CSRs, PR and JLS, so 
>>>> stay tuned. As always, comments are welcome.
>>>>
>>>> Cheers,
>>>>
>>>> — Jim
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230327/81ab731b/attachment-0001.htm>