Consider merging TemplateProcessor into RefasterTemplateProcessor

[timtebeek]

What problem are you trying to solve?

Right now we maintain two separate processors, TemplateProcessor and RefasterTemplateProcessor which each produce Java files. These are then stitched together through Semantics, PatternBuilder and reflection.

rewrite-templating/src/main/java/org/openrewrite/java/template/internal/PatternBuilder.java

Lines 30 to 39 in 022373a

	public JavaTemplate.Builder build(JavaVisitor<?> owner) {
	try {
	Class<?> templateClass = Class.forName(owner.getClass().getName() + "_" + name, true,
	owner.getClass().getClassLoader());
	Method getTemplate = templateClass.getDeclaredMethod("getTemplate");
	return (JavaTemplate.Builder) getTemplate.invoke(null);
	} catch (ClassNotFoundException | NoSuchMethodException | InvocationTargetException |
	IllegalAccessException e) {
	throw new RuntimeException(e);
	}

I think originally we had developed these separately with the idea that the generated templates could also be used independent of any generated Refaster recipe. In practice this hasn't happened, and I don't immediately see that happening still.

Describe the solution you'd like

I think we could merge the two into a single processor now and take out the extra generated classes and reflection glue.

Have you considered any alternatives or workarounds?

• Keep these as-is.
• Have RefasterTemplateProcessor call a method on TemplateProcessor to inline the templates.

[knutwannheden]

I disagree. I think there is yet use for the annotation processor we use to process the Semantics calls, when more complex recipes than what can achieved with Refaster are required, yet, either the matching or templating mechanism based on lambdas is still desired. I think we have some examples in rewrite-micrometer.

This being said, I think it could still make sense to basically "inline" the templating processor into the Refaster processor, so we don't have to produce more Java source files. But also this has pros and cons.