Within the past two years I was working on two Xpand to Xtend2 migration projects. In this post I sum up some of the experiences I made with the two generator template languages. The experiences are based on Xpand 1.2.1 and Xtend 2.4.1.
Xtend2 good parts
It is possible to debug Xtend templates in Eclipse. This is a very helpful feature and was not possible with Xpand before. The overall tool support for Xtend is better.
It is no more necessary to learn two or three languages. Instead of coding in Xpand, Xtend1 and Check it is possible to simply use Xtend for everything. Xtend is a very nice, concise and powerful language and by far not so boilerplate like Java. Actually Xtend is a GPL and could be used as a replacement to Java.
Generating with Xtend is a magnitude faster than generating with Xpand. The Xtend compiler is quite slow, but if Xtend is already compiled to Java, a generation process will run very quickly. Xtend templates are compiled to Java in advance and not interpreted like the Xpand templates.
Another benefit is that generating with Xtend templates results in a way cleaner output. There are no more endless unwanted empty lines or whitespaces in the generated end results. The output is usually very well formatted and there is no extra formatter required.
But be aware, there are also some bad parts…
The not so good parts of Xtend2
So far editing Xtend 2 in Eclipse is still darn slow. And the editor itself provides not much tool support. It is better then the tool support for Xpand, but there are almost no refactoring’s. The few simple refactoring’s that are provided are very unreliable and produce Exceptions. If there were no code completion and syntax/error highlighting I would recommend using a simple Text editor instead of Eclipse.
Xtend is a great language. Java developers will love it. Maybe some day the IDE support in Eclipse is better and the compiler faster. Then I guess Xtend will receive a lot more attention and adoption. The language on its own has a lot of potential and I like its syntax over Groovys, Scalas or Javas syntax.
During the development of Xpand templates and Xtend files it is sometimes useful to print information to the console. The Eclipse plugin org.eclipse.xtend.util.stdlib helps with this. To be able to print to the console just add the dependency
to your project like in the following figure.
Afterwards Xpand files need the following line of code.
I started to write an IntelliJ Plugin for Xtend a while ago and now I am happy to be able to blog about what I have got so far for the first time. Until now there is only basic syntax highlighting available, but it looks already pretty promising. My hope is to be able to do all my Xtend coding in IntelliJ in the future with nice refactorings, error reporting, intentions etc.
Here are two IDE editor screenshots. The first one is the well known Eclipse Xtend Editor.
The second IntelliJ IDEA with Xtend support! :-D
Until now there is no official release out and I guess it will also take quite some time until then. There is still a lot to do and I don’t have much time to work on the plugin. The plugin has to evolve little by little. You can find the source code on github if you are interested in the development.
This post shows how to patch an existing Java Archive (JAR) to add new functionality to it or change its behavior. This for example can be helpful to add some logging for debugging purposes.
Import ‘Plug-ins and Fragments’ into Workspace
Under ‘Import As’ mark ‘Projects with source folder’
Chose the project you want to modify (Target platform)
Locate the source file in the workspace/project and modify it
Now do a right-click on the file to figure out where it is located
Leave Eclipse and go to the command line and ‘cd’ into the Eclipse workspace
cd into ‘bin’ and execute the following command
$ jar uvf theJarFile.jar ./com/example/etc/ModifiedJava*
Now it is possible to see the new logging stuff or whatever you did to the Java class. Be aware that this might cause severe problems or side effects in case someone else is depending on this file. ;-)
The following snippet helps to find a particular class file within a big junk of JAR files. This might help if you want to scan a local Maven repository.
find . -name *.jar | while read jarName; do echo "JAR: " $jarName; jar tf $jarName; done | grep "JAR:\|TheJavaFileIAmLookingFor.class" --color=always
If you are confronted with the following log warning message you are facing a name collision in an Ecore generated from a XSD.
WARN OawXSDEcoreBuilder - Name Conflict: Created EAttribute
'group1', EAttribute 'group' is in the way.
As the XSD choice tag has no name attribute the org.eclipse.xsd.ecore.XSDEcoreBuilder will set the corresponding EAttribute name to ‘group’ by default. Well this happens when the choice tag also has the attribute maxOccurs=”unbounded”.
The following code snippet will reproduce such a log warning message.