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 <[email protected]> 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
