Replace Xtend with Java

[PhilippSalvisberg]

In the Xtext release notes of version 2.20.0 you find the following about "Xtend"

A word on Xtend. Back in 2013 Xtend was the “Java 10 of today” 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. 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.

IMO Xtend is really superior in the area of string templating. It's used to build SQL statements in this project. However, this is not a code generation project. Therefore we can live with inferior Java features in this area. Java 13/14/15 text blocks would address some issues, but not all. Anyway, In this project we have to stick to the Java version used by SQL Developer. The current version of SQL Developer 19.4.0 supports JDK8 or JDK11. The user chooses the exact version. Hence we have to stick with JDK8 for the moment.

Moving from Xtend to Java will have the the following positive impact:

• reduced compile time
• IDE independence (Xtend works quite good in Eclipse but the IntelliJ support has been dropped)
• better debugging experience (no bridge between Xtend and Java representation)
• more inclusive / simplified contribution (because Java is much more popular than Xtend)
• reduced size of final artefact (no Xtend runtime libraries required).

But there is also a negative impact:

• more verbose code due to missing, equivalent feature in Java (see also Xtend features)
  • Extension methods (used)
  • Lambda expressions (used, but there are acceptable options in Java8)
  • Active annotations (used)
  • Operator overloading (used)
  • Switch expressions (used)
  • Polymorphic method invocation (used)
  • Template expressions (used)
  • Properties (used)
  • Type inference (used)

Xtend generated Java5 code. However, this code is not meant to be maintained manually. It looks ugly and since it was originally based on Java5, it does not use Java8 features where possible (e.g. for lambda expression). Hence the migration from Xtend to Java is a semi-automated process, where the generated code might be used as a starting point only, but must not be used 1:1.

A migration is possible class by class. However, I suggest to do it for the whole project including tests.

[Pazus]

Btw have you considered Kotlin?

[PhilippSalvisberg]

Yes I have. Especially since there are a lot of similarities with Xtend. I would have liked to use a JVM language with multiline text blocks in string literals. However, I decided for Java because of popularity (even if Kotlin seems to be now the 2nd most popular JVM language according this post) and because we are using it as the JVM language of choice in the other utPLSQL projects.

And I have already started to migrate classes to Java. Painful. Commits to local branch. Not pushed yet.