Devoxx 2013, Day 1

We are back again. The ConSol posse enters Devoxx again and will posts some expressions from this largest independent Java conference. Roughly 3500 attendees transform Antwerp into Java’s epicenter for one week.

And as always, this weeks starts with two university days. Fabian, Mario, Julian and Roland attend the whole conference, Christoph, Thorsten and Jan will arrive today for the three conference days.

So let’s see what was on staged at the first day

“Java EE 7: What’s new in the Java EE Platform” by Arun Gupta, David Delabassee and Antonio Goncalves (fabian)

Arun Gupta and Antonio Goncalves were holding a 3 hour in-depth walk through all of Java EE 7. For each of the JSRs, they showed examples of what’s new in the current version. The code samples are available on Arun Gubta’s GitHub page:

Questions and comments where provided live via Twitter and where read during the talk, so if you want to have an impression on the discussed topics, check for hash tag #DV13-UniJavaEE7.

The point I found most interesting is that EJB will eventually be split into a bunch of independent JSRs, one for each feature. Interceptor API is already part of JEE, transactional methods are now enabled via JTA and can be used independently of EJB. Seems that EJBs are no longer needed in many cases.

However, with Glassfish no longer commercially supported, it will take some time until we see those new features in production.

“JVM bytecode engineering 101” by Kees Jan Koster (mario)

Kees Jan Koster is founder of and he shares his knowledge
about JVM bytecode in his talk.

At first he has showed how to inject bytecode into existing classes. The use case was to find
out which class is closing an SQL connection inside a deployed tomcat webapp. To get the result,
he created a javaagent which modifies the Java-SQL-Connection-Class
to print the stacktrace when the method ‘close()’ is called. To get the result, he created
a class which implements the interface ClassFileTransformer

It has a method ‘tranform’ which is called before the classfile-verifier. The method gets from
every loaded class the bytes as parameter. You can modify the bytes, so you can change the loaded class.
To modify the classbytes he showed three different libraries to make this easier.


  • High level
  • Need classloader.
  • Add bytecode as written javacode.


  • Low level
  • Use vistor-pattern to add bytecode to classes.


  • Low level
  • Maybe dead

At the second half he showed examples how javacode looks as bytecode.
This part gave a deep knowledge how bytecode interact with the stack
and what optimizations are done with types.
Especially very surprising was how bloated the bytecode is, when ‘try finally’ is used.
The code inside the finally code will be doubled.

In my opinion this was a very interesting talk. Now I know a lot more about bytecode and
how I can modify it inside the JVM. Some additional information was given by an ASM developer
in the audience who clarified some points.

But one question is still to discuss. When will I need to act with the bytecode directly when I
have a lot of high level tools like a debugger?

“Phantom, Zombie & Karma: overview of the greatest testing tools for modern web apps” by Jean-Laurent de Morlhon and Pierre Gayvallet (roland)

This three hour university talk gave a broad overview of the testing tools available in JavaScript land. After a general introduction into testing and the several flavors of testing (unit, integration, acceptance) a whole bunch of thesting tools were presented, along with their pros- and cons


PhantomJS is a pure headless browser which is QtWebkit based. It provides an embedded Coffeescript compiler and allows saving screenshots to disk. It has some limitations, though:
- No flash
- CSS 3D
- Video / Audio
- WebGL
- Geolocation, Fonts

PhantomJS is not a test framework but the foundation for a other tools like …


CasperJS adds a higher API to PhantomsJS with a fluent JavaScript API.

  • Pros
    • Higher Level API
    • Veryf fast
    • xUnit export
    • easy to exten
  • Cons
    • Test API not mature
    • Python or Ruby launchr required (problematic windows)


Zombie is similar to CasperJS as it is a testframework for writing acceptance tests. Againg, its a headless browser, but it is not based on a real browser engine. Instead it emulates as browser and runs on node.js.

  • Pros:
    • Ultra fast
    • Fluent API
    • Test code is good to read
  • Cons:
    • Emulation only
    • No windows
    • Errors are cryptic
    • Java build integration difficult
    • Main developer says “it’s a side project only”


QUnit is a lightweight testing framework running in the Browser. It is intended for unit testing and is able to ouput xUnit format, which makes it easy to integrate into CI tools like Jenkings. It’s quite old, but also very matured with a lot of plugins for various purposes.


Sinon.js is a test library for JS with no dependencies. Its more or less similar to Java Mockframeworks like Mockito, EasyMock or JMock for Java. However, it has also unique features like Spies, fake timers or fike Ajax requests.

  • Pros
    • Powerful and readable API
    • Spies and Stubs are the best mock implementations out there.
  • Cons:
    • Ajax faking is not good on IE6/7
    • Date faking might break date libraries
    • No easy way to call original method from a stubbed one


Karma is a test runner for node.js with Multi Browser support. It comes from the Angular war and supports many test frameworks, i.e. Angular Scenario for integration tests. However, currently Angular itself is moving away from Karma in favor for Protractor for acceptance tests. Intrestingly, Karma on Chrome is quite a bit faster than PhantomJS.

  • Pros
    • Multi, “real”, Browser support
    • Angular Scenarion
    • Fast
    • Can watch files and run tests continously
  • Cons
    • E2E on Angular only
    • Documentation not very complete
    • Separate Installation of Browsers
    • Verbose configuration file
    • Could become obsolete for E2E testing when Protractor kicks in.

Finally some smaller test tools were mentioned briefly:

  • Mocha is a test Framework for unit tests, running on node.js or in a browser.
  • chai.js is an assertion libray offering multiple styles
  • Buster.js is a test runner like Karma, which ships with sinon.js. It has some unique features like the possibility to specify test prerequisites. Although it is a very young library, it is quite promising.
  • JSCover is a Javascript code coverage tool, which can be applied either during build time or as a proxy during runtime. (Istanbul might be an interesting alternative here, though)
  • Plato is a visualizer for JavaScript complexity

All in all I took away a tons of information about JavaScript testing and have now tons of pointers to check out. There where many demos, which was good. However, some of the demos were to trivial, simply only repeating was on the slide just before. What I missed a bit was some recommendations how to integrate the test tools in a build, either with grunt or brunch or, even better, with Maven or Gradle (dedicated plugins ?, simple ‘exec’ ? etc.). A last technical note: The beamer in room 9 is really too fuzzy and blurry. It was really hard to follow the code samples, even with a large font. Hopefully this can be fixed, the projections in the other rooms is quite better.

Author: Roland Huß
Categories: devoxx, development