Support Kotlin-based templates #218
Comments
To allow the `JavaTemplate` mechanism to be used for other languages like Kotlin, the provided parser builder must provide a way to add a classpath entry. This is because the internal `__M__` and `__P__` types are required for the parameter substitution and rather than including them as source code in the compilation unit, the parser will load them from the classpath. To this end this PR introduces new `JvmParser` and `JvmParser.Builder` types and the `JavaParser.Builder#classpath()` methods are moved to `JvmParser.Builder`. In order to not increase the API surface area, no corresponding getter was added to `JvmParser.Builder`. Instead, there is a new `Internals` class providing a static `getClasspath(JvmParser.Builder)` method. Issue: openrewrite/rewrite-kotlin#218
|
Hey @knutwannheden, This feels syntactically possible, would provide some level of compatibility for existing recipes written using |
|
This is indeed an interesting topic. While the Kotlin printer should be able to print a J tree (since K is an extension of J), the code would in many cases not be idiomatic Kotlin code and I am afraid it would in many cases not even be correct code. This then indeed requires some type of transformation. We do have a concept for how a JavaVisitor can be adapted so that it can be adapted by a KotlinVisitor to also be able to process Kotlin LSTs, but we are still investigating how to best use this to make Java recipes applicable to Kotlin code. Further, this would not really help when a recipe uses JavaTemplate to emit new code. We haven't yet worked out how exactly these things should all fit together, but we would definitely want as many Java recipes as possible to be compatible with Kotlin. Independent of this I think it makes sense to have a KotlinTemplate which allows Kotlin developers to more easily author Kotlin recipes. |
|
Agreed, And I think that starts to answer some of the questions I raised over here: I suppose it wouldn't take much code to play with using the kotlin printer on a J tree on my machine; I'd be curious to see just how far it can be from valid (even ignoring idiomatic) |
* Add new `JvmParser` as supertype to `JavaParser` To allow the `JavaTemplate` mechanism to be used for other languages like Kotlin, the provided parser builder must provide a way to add a classpath entry. This is because the internal `__M__` and `__P__` types are required for the parameter substitution and rather than including them as source code in the compilation unit, the parser will load them from the classpath. To this end this PR introduces new `JvmParser` and `JvmParser.Builder` types and the `JavaParser.Builder#classpath()` methods are moved to `JvmParser.Builder`. In order to not increase the API surface area, no corresponding getter was added to `JvmParser.Builder`. Instead, there is a new `Internals` class providing a static `getClasspath(JvmParser.Builder)` method. Issue: openrewrite/rewrite-kotlin#218 * Correct bounds on `JvmParser.Builder` * Make `JvmParser.Builder` constructor protected * No need for initializer block when templating context-free expression * Expose more of `JavaTemplate` engine API for extension * Remove `JvmParser` and `Internals` again * Make `Substitutions` extensible * Lazily initialize `TEMPLATE_CLASSPATH_DIR` at runtime * Add `BlockStatementTemplateGenerator#TEMPLATE_INTERNAL_IMPORTS` * Correction to `Substitutions` after merging * Rename new `addClasspath()` to `classpathEntry()` * Remove unused `JavaTemplate#parameterCount` * Update rewrite-java/src/main/java/org/openrewrite/java/internal/template/__M__.java * Update rewrite-java/src/main/java/org/openrewrite/java/internal/template/__P__.java * Revert accidental visibility change * Fix problem with classpath in `JavaParser.Builder`
|
What problem are you trying to solve?
When modifying Java code the safest and often easiest way is to use
JavaTemplate. For Kotlin this is currently not possible, becauseJavaTemplateuses aJavaParser(and not aKotlinParser) and there is no corresponding mechanism inrewrite-kotlin.Describe the solution you'd like
Modify
JavaTemplate(inrewrite-java) so that it can be provided with aKotlinParserrather than aJavaParserand then use this mechanism to parse context-free templates.Supporting context-sensitive templates will be more work and will probably require a new
KotlinTemplatetype.Have you considered any alternatives or workarounds?
Additional context
Are you interested in contributing this feature to OpenRewrite?
The text was updated successfully, but these errors were encountered: