Why Replace Xtend?<\/h2>\n\n\n\n
Xtend is a statically typed, clean language with excellent string templating features and a fine integration into the Eclipse IDE. From a technical point of view it is an excellent choice for code generation projects, especially if you are a happy user of the Eclipse IDE.<\/p>\n\n\n\n
In the Xtext release notes<\/a> for version 2.20.0 – released in December 2019 – you will find the following statement about “Xtend”:<\/p>\n\n\n\n A word on Xtend. Back in 2013 Xtend was the \u201cJava 10 of today\u201d even before Java 8 was out. Meanwhile Java Release cadence has speeded up and many of Xtends features can be achieved with pure Java, too. There is still some areas where Xtend is particularly advanced like Code generation, Unit tests and lambda heavy APIs like JvmModelInferrer and Formatter. For other tasks there is no need to use Xtend.<\/span>\n Also the resources we have no longer allow us to keep the head start against Java. And learning Xtend still is a burden for new Xtext users. To reflect this changed situation we have decided to make Java the default in the wizard again (except e.g. the Generator and a few other APIs). You can still decide if you want Java or Xtend in the workflow.<\/p>\n<\/blockquote>\n\n\n\n The situation of Xtend has not improved. Quite the contrary. In the release notes<\/a> of Xtend 2.22.0 – released in Juni 2020 – you find the following statement prominent at the beginning:<\/p>\n\n\n\n As you might have recognized, the number of people contributing to Xtext & Xtend on a regular basis has declined over the past years and so has the number of contributions. At the same time the amount of work for basic maintenance has stayed the same or even increased with the new release cadence of Java and the Eclipse simultaneous release. Briefly: The future maintenance of Xtext & especially Xtend is at risk<\/span>\n. If you care, please join the discussion in https:\/\/github.com\/eclipse\/xtext\/issues\/1721<\/a>.<\/p>\n<\/blockquote>\n\n\n\n The above mentioned GitHub issue was created in late March 2020 and referenced on Twitter<\/a>. My current assessment is that Xtext will survive and Xtend will eventually die. This assessment was the main driver to think about replacing Xtend in the utPLSQL code base.<\/p>\n\n\n\n SQL Developer runs on a JVM (current LTS versions 8 and 11 are supported only). Hence, extensions have to be written in a JVM language. The utPLSQL extension generates some code and SQL statements. Therefore a language supporting multiline strings would be helpful. Options are<\/p>\n\n\n\n However, the support for multiline strings in all these languages is inferior to what Xtend provides. The template expressions<\/a> of Xtend are extremely powerful. It’s a statically typed code templating language after all (sigh, there is no adequate replacement for that).<\/p>\n\n\n\n I had a closer look at Kotlin, since the grammar has a lot of similarities with Xtend and it seems to be the rising star according to the JVM ecosystem report<\/a>. However, it requires a runtime library and the support of the language is very much IDE dependent. As with Xtend, just the other way around. This means, excellent support in IntelliJ IDEA, but significantly weaker in the Eclipse IDE.<\/p>\n\n\n\n At this point I stopped evaluating other JVM languages and decided to go with Java for the utPLSQL extension. The support of Java is excellent in any Java IDE. No wonder, Java is by far the most popular JVM language. Furthermore Java is used in the other utPLSQL projects (Java API, CLI and Maven plugin). This simplifies the contribution to the project. And last but not least I expected the least effort for the migration when using Java as the target language.<\/p>\n\n\n\n\n
\n
Why Java?<\/h2>\n\n\n\n
\n
Migration Approach<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.salvis.com\/blog\/wp-content\/uploads\/2120\/05\/Xtend-to-Java-Migration-Approach.png\")
<\/a><\/figure>\n\n\n\n