StringTemplates name changes
Jim Laskey
james.laskey at oracle.com
Mon Mar 27 14:46:57 UTC 2023
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><mailto: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/9a525f72/attachment-0001.htm>
More information about the amber-spec-experts
mailing list