I’ve updated the spec change document to reflect this change: https://cr.openjdk.org/~gbierman/jep430/latest/
Thanks, Gavin On 27 Mar 2023, at 14:07, Jim Laskey <[email protected]> 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 <[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
