Manual Oracle JDK installation on Ubuntu

The first step is to download the desired Oracle JDK as .tar.gz file from the website. Afterwards extract the downloaded file.

cd /usr/lib/jvm
tar xf myjdk.tar.gz

Install and config

Use update-alternatives to create symbolic links to the new JDK.

The 1 in the end is the priority. When a link group is in automatic mode, the alternatives pointed to by members of the group will be those which have the highest priority.

sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/myjdk/bin/java" 1
sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/myjdk/bin/javac" 1
sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/myjdk/bin/javaws" 1
sudo update-alternatives --install "/usr/bin/jar" "jar" "/usr/lib/jvm/myjdk/bin/jar" 1

# The following is obsolete if there are no alternatives

sudo update-alternatives --config java
sudo update-alternatives --config javac
sudo update-alternatives --config javaws
sudo update-alternatives --config jar

Firefox Plugin

cd /usr/lib/mozilla/plugins # ~/.mozilla/plugins/ is also possible
ln -s /usr/lib/jvm/myjdk/jre/lib/i386/

Final steps and verification

Set a symlink for the $JAVA_HOME variable with the following command.

sudo ln -s /usr/lib/jvm/myjdk /usr/lib/jvm/jdk1.7.0

Globally create the JAVA_HOME system environment variable with

vi /etc/profile

… and add the following

export JAVA_HOME="/usr/lib/jvm/jdk1.7.0"
# ... and more stuff if you like for example maven opts
export MAVEN_OPTS="-Xmx2G -XX:MaxPermSize=1G"

To verify everything went well execute the following commands.

java -version
javac -version

Xtend2 compared to Xpand

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.

Final words

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.

How to print debug information to console with Xpand and Xtend1

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.

Ecliipse Demendecy Manager

Afterwards Xpand files need the following line of code.

«EXTENSION org::eclipse::xtend::util::stdlib::io»

Xtend files need the following line of code.

extension org::eclipse::xtend::util::stdlib::io;

String doSomething(String str) :
    info("HALLO") -> e | == str)).first().info();

Add 2560×1440 resolution for Dell U2713H monitor under Ubuntu 13.04 connected over HDMI

This post describes how to configure Ubuntu 13.04 for a Dell U2713H monitor with a 2560×1440 resolution. It also works for Ubuntu 13.10.

Open a terminal and execute.

cvt 2560 1440 60

The resulting output on the console is needed to create a new monitor resolution setting and might look like the following.

sven@c:~$ cvt 2560 1440 60
# 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz
Modeline "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync

Create a new file /usr/share/ with the following content.

xrandr --newmode 2560x1440 312.25  2560 2752 3024 3488  1440 1443 1448 1493 -hsync +vsync
xrandr --addmode HDMI2 2560x1440

Make the file executable.

sudo chmod +x /usr/share/

The last step is to add the following line to the end of the file /etc/lightdm/lightdm.conf


Migrating a code base from one language to another

During 2012 I migrated a Xpand and Xtend1 code base to its successor Xtend2, today simply called Xtend. During the project I made the folllowing experiences.

  • First try to clean up the old code base a little before starting to migrate! Small stuff will help already.
    • Talk to the developers involved in the project and ask for stuff that isnt used or needed anymore. There will be planty. And wasting time on this is just nonsense.
    • Try to find duplicated code.
    • Try to reduce the dependencies between classes, modules etc.
  • Always have a running system while migrating. Use an adapter for example to iterativly replace the old system step by step with the new one until the migration is 100% completed.
  • Do small noninvasive changes. Migrate the smallest file with smallest possible impact first.
  • Write many tests to prove that the behavior of the migrated code is the same.
  • Don’t do any refactorings on your way!!! Don’t do it! First successfully complete the migration and write lots of tests. Only afterwards do refactor the migrated code.

IntelliJ IDEA Xtend Plugin

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.

Eclipse Xtend Editor
Eclipse Xtend Editor

The second IntelliJ IDEA with Xtend support! :-D

IntelliJ Xtend Editor
IntelliJ Xtend Editor

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.

Patching JARs with the help of Eclipse

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.

  • Open Eclipse
  • Import ‘Plug-ins and Fragments’ into Workspace
  • Under ‘Import As’ mark ‘Projects with source folder’
  • Next
  • Chose the project you want to modify (Target platform)
  • Locate the source file in the workspace/project and modify it
  • Save changes
  • 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

Avoid name collision in Ecore generated from XSD

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.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns=""

  <complexType name="Frucht">
    <choice maxOccurs="unbounded">
      <element name="a" type="string"/>

  <complexType name="Apfel">
      <extension base="example:Frucht">
        <choice maxOccurs="unbounded">
          <element name="b" type="string"/>

To prevent this collision one can add the Ecore namespace to the XSD file and add a name attribute to the choice tag.

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns=""

  <complexType name="Frucht">
    <choice maxOccurs="unbounded">
      <element name="a" type="string"/>

  <complexType name="Apfel">
      <extension base="example:Frucht">
        <choice maxOccurs="unbounded" ecore:name="apfelChoice">
          <element name="b" type="string"/>

With the additional ecore:name attribute the corresponding EAttribute won’t receive the name group anymore and there is no conflict.


Xtend lambda expression type definitions with and without syntactic sugar

The usual or shortest way to write a lambda expression in Xtend is to leave out the type information. Xtend2 works with local type inference so there is no need to explicitly write down the type.

val myFunction = [String a, String b | a.compareTo(b)]

There is a special short syntax for lamda expression type definitions in Xtend2 that looks like the following.

val (String, String)=>int myFunction =
    [String a, String b | a.compareTo(b)]

The most verbose way to write a lambda expression in Xtend2 is the following. It has the long full type definition and also the optional round brakets around the expression itself.

import org.eclipse.xtext.xbase.lib.Functions.Function2

val Function2<String,String,Integer> myFunction =
    ([String a, String b | a.compareTo(b)])

In the last and most verbose example one can see that the local type inference is really helpful as the first example is a lot easier to read.

The examples were written and tested with Xtend 2.2.1