WJax 2014

Well, first of all, thanks to @rheinjug, for providing me with the tickets, I’ve won! Yeah! ;))

For me conferences are always a good time, and I really like the energy and inspiration I draw from a conference. And WJax was no difference!

Let’s dive right into of what I saw at WJax 2014.

The basics

It’s quite a large conference in a large venue, I would guess around 2000 people there. The overall setup was very good: Large enough rooms, little technical difficulties, good tram connection, nice food, not that much queueing up and acceptable WIFI coverage. Have seen this far worse, thumbs up!

Sadly the conference was overshadowed by a strike of the german train union, so lots of people had some difficulties getting back home. Quite some conversation went about that. But the organizers did a good job communicating this and trying to leverage things.

The topics


The main topic this time was ‚Microservices‘ and all the things buzzing around that term: Docker, DevOps, Cons/Pros of the Application Server.

I think the idea of Microservices sounds quite appealing: Small, self-contained and focussed applications.
One the one hand Microservices might help you prevent monolithic architectures, allow you to establish quicker turnaround times and give you and your team some sort of organisational independence,
On the other hand, if your system consists of too many Microservices you might experience something like a Microservice hell.
Newer companies like Etsy, Netflix or Groupon use and/or coined some of those microservicy ideas.
Stefan Tilkov did a very good one about this. He presented ideas how you can borrow some of these newer architectural approaches in an existing enterprise world. Liked that. I think we will stumble upon some of those concepts sooner or later.

Docker provides tooling to assist you in achieving quicker turnaround times for your applications. It allows smart packaging of your application and its context (i.e. OS), so you could take your application (and its container/os) from your dev box to your staging and production environment.
Loads of talks about that. There seem to be rough edges here and there (Continuous Delivery tool support, dealing with databases, clustering, etc ), but nonetheless a very influential and promising tool. It naturally shines, when used in an DevOps environment.

The discussion about whether we still need an application server or not is closely related.
On the one hand people argued, that the application server provides a stable ground, which may need some refinement here and there.
On the other hand people said, the application server is too big, needs application specific adjustment anyway, does not allow you to port a random JEE application, that vendors are too slow, etc.
Some kind of middle ground was the notion to use a plain tomcat with spring, instead of waiting an average of 3 1/2 years to be able to use a newer JEE version.

One surprising outcome for me was, that most people on this conference agree on the 1:1 relation between an app and an appserver. Given that it would not be a harsh step to embed some kind of server in the application itself.

Some talks dealt with REST and Hypermedia. Learned how this could make your application logic more transparent. Things seem to be a little rough and ‚in progress‘ in that field.

I somehow managed to miss the talks dealing with ‚reactiveness‘ altogether. Important topic. Shame on me.


Though there was a JavaScript day I would have expected a little more buzz around AngularJS and JavaScript.
I saw an interesting talk how to combine AngularJS and TypeScript. I like how TypeScript provides with optional typing, the usage with AngularJS seems a little clunky to me. AngularJS 2.0 seems to go that way, we will see if that feels better.

I missed one talk that summarized the current state of JavaScript development.  Did not sound promising looking at the abstract, but reviewing the slides, it seemed to have been great.

Non Dev stuff

Two of the best talks I saw at WJax were both dealing with non dev stuff.

One talk by Elmar Jürgens was about the proper usage of quality measurement tools and processes in your project: Use simpler metrics, don’t control the developers, don’t show quality numbers to management unless you provide context to those numbers. Entertaining talk and well done slides!

The other talk by Stefan Toth was about architectural decisons and how you can defer them. It presented no fundamental new insights, but it showed the idea to explicitly use and try to extend a learning phase, to make your decison more elaborate. You will know more about your project as time passes by. Also very entertaining talk and great slides! Thanks to Stefan Zörner for pointing me at this talk.

Java 8 / JEE 7 /Spring

Quite some talks, but I felt that I heard most of those topics elsewhere. An interesting one by Lars Röwekamp questioned existing JEE Patterns.
I am a little bit tired of Java 8 and JEE7 talks. I want to finally use it in everday work. And it seems to me that I am not alone in that.
Not that much on Spring, though Spring Boot (a way to build self-contained applications) looks promising to me.

Alternative Languages

Is saw very little on alternative JVM languages, though I heard a good talk by Silvia Schreier and Philipp Schirmacher about real world Clojure. I always wondered how Clojure would work in an ordinary web app. This talk showed it and saved me some time.

What else

Other notable bigger topics, that I not dug deeper into were the Internet of Things (IoT) and white collar stuff like BPM and friends.

The conclusion

Hell of a lot of talks. It was a difficult decision all the time, I probably missed some more good ones.

Less geeky than for example Devoxx, more focussed on business IT. Which could be either good or bad. Though I appreciate the nerdy and perhaps more visionary approach of other conferences, I liked the „down-to-earth“ (if you might call it so) approach. The attendees seemed to work in similar contexts. So I could connect to most of the experiences that were presented. I would definitely go there again, if getting the opportunity.

What is a unit?

Recently we had a discussion in our team regarding good testing practices (again) :)
With this post I try to summarize this discussion for myself.

The system under test

We were developing a piece of software exposing a REST-Interface using Spring for all kinds of things (REST-communication, DI, Hibernate integration, etc.)

Many of the tests already in place made use of the SpringTestRunner. Most of these tests were declared ‚unitests‘. I did not regard this as a good practice using test which boot up Spring (and quite a lot of the adjacent dependencies of the springbeans) as our lowest level of tests. Some team members defended those tests as it is the most convenient way for them to write tests. Anything less was not regarded helpful to show any meaningful failures.

In my book a unit test does not need the presence of a containing framework. The test take less time and you can express your dependencies more clearly when you state them explicitly. It helps me to mock out those dependencies if I don’t need them in my test.
Spring should only help to glue those pieces seamlessly together.

But we thought this may not be a Spring issue, so we tried to take this discussion to a more general level.

Taking it to a general level

Basically it boiled down to the questions:

  • How do we test?
  • In which extend do we test each layer?
  • Of which granularity should our tests be?

We agreed to some extent to applying TDD and
having read [Growing Object-Oriented Software, Guided by Tests]1, we assumed we had a similar understanding of what ‚testing‘ means regarding that context.

To quickly summarize [Growing Object-Oriented Software, Guided by Tests]1:
The book describes two essential feedback loops:

  1. One outer loop, containing the acceptance tests
  2. Several inner loops containing the unit_test

Comparing our way we drive development by tests, we encountered subtle differences

  • I put more emphasis on the unit test
  • My teammate put more effort in acceptance tests or coarse grained tests, as the seem to have more realworld value

To understand where this difference might come from, we got back to the picture (pictures do always help, don’t they ;) of the TestPyramid:

  • In my case it took the form of the pyramid, putting most emphasis on the unit layer.

unitTest PostingPyramide

  • In his case it took the form of a diamond, having more enphasis in the middle layer.

unitTest PostingPyramide2

As one result my teammate stated, he was not fond of the term ‚unittest‘ as it is too vague for him. In his eyes it could mean anything. It may even be a strictly technical term derivied from the TestRunner, as a testcase is often implemented as a JUnit Test (yes, we have a Java background). So every test done by JUnit could possibly be regarded as a Unit test.

I disagreed and insisted that the term Unit in Object-oriented software is commonly defined as of being the class you’re looking at.

He proposed a different term for that matter.
For above reasons i rejected this for now as I saw no need for another overloading of words.


As we didn’t come to a conclusion, we agreed on doing do a short survey in our team, and possibly elsewhere, stating the question:

‚How do you define the term unit in Object Oriented Software?‘

As a result we had (surprisingly) many definitions of „unit“

  • Everything run by JUnit
  • Unit is a class
  • Unit is everything
  • Unit is not defined

I took this discussion outside of our team and asked the same question. While some quickly replied with ‚A unit refers to a class in oo‘, I got one rather interesting definition:

@DerTeta said:

Everything that has an interface I can write tests
against. Have hit the occasional wall with this
definition, though.


If I can test it in isolation (i.e., without db, etc.) I
consider it a unit. Anything else is blurry.

While I question part one of this statement. (A UI has an interface but tests using this interface are mostly no unit tests), part two is rather important to me.
A unit test with all its dependencies mocked out is clearly tested in isolation23. It depends on the thing and the intent of your test, how much you loosen this isolation statement. You may not need to mock out your domainmodel, perhaps you don’t need to mock out some other helper structures, if they don’t blur the intent of your test. But things like a DB, a service call, a complex algorithm or be it some framework dependency (JSF or maybe Spring), might violate the isolation of your test to some degree and possible test failures might be harder to spot.

Coming back to the starting point

I still don’t think that the SpringRunnableTest serve a good purpose as a unittest, when you apply a TDD approach. They come with a additional load and for many testcases you don’t need Spring in place, though it might it might come handy at times that your dependencies are kicked in externally. I still do like them, when used in higher layers of the testpyramid.

If the part you are about to build is not that complex – say some more straightforward CRUD part – SpringRunnableTest (as a more diamond like approach) might serve you well.
Also if you do prefer a more ‚acceptance-test-centric‘ approach (with Spring in place and the testconfiguration at your service), you might treat and design them in a unittest-like fashion.

But I’ve often seen those tests degenerate from a unittest to an integration test (yet still be named unittest), becoming dependent on the outside world and becoming slower and more brittle.


Another colleague showed us a handy technique using Mockito that I haven’t come across yet (Though I used mockito before, shame on me!). To avoid Spring dependency injection, and to avoid handrolling all your mocks Mocktio comes with a similar feature, that allows you to define mocks and inject them in a more concise manner link.
I kind of like this approach, but some of my initial criticism kicks in here as well. The definition of your dependencies becomes more implicit. But compared to starting up Spring this approach seems to be way faster and your tests become more readable.
What about isolation? As I see it, my CuT is still run as isolated as done without mockito-trickery, only your test-class becomes dependent on mockito.
This may be the best of both worlds, let’s see if this technique helps that a unittest remains a unittest over time.

  1. http://www.amazon.de/Growing-Object-Oriented-Software-Guided-Signature/dp/0321503627 „Growing Object-Oriented Software, Guided by Tests“ 
  2. http://martinfowler.com/articles/mocksArentStubs.html#TestIsolation „Martin Fowler, Mocks aren’t Stubs“ 
  3. http://artofunittesting.com/definition-of-a-unit-test/ „The Art of Unittesting“ 

My personal IntelliJ top features

I have been using Eclipse more or less heavily for the past 10 years now.
For my last project I decided to give IntelliJ a spin. And as it turned out, I like it! IntelliJ does many things a little bit better than Eclipse.
This list should highlight those ‚little things':

  1. Maven Integration
    • Maven Integration works smoothly, unmatched by Eclipse
    • Maven is mostly hidden from you
    • If you have to use maven, there is comfortable tools support
  2. Jump to test
    • Quickly see related tests for a class
    • Nice companion for tdd
  3. Find resource
    • Nice in Eclipse, this really feels like Spotlight/Alfred on Mac
  4. Live templates
    • Quickly generate boilerplate code
    • More poweful than Eclipse
    • Extensible
  5. Code Completion everywhere
    • Even in the debugger view!
  6. Facelets editor Smooth code-completion based on taglibs
  7. Spring editor: Show resolved property from config
  8. Team city integration: Pre Tested commits/Run test locally
    • Keeps your repository clean
    • Less broken builds
    • The option is quite hiddem
  9. Subversion: Show Outdated version while editing
    • Quickly see you might want to update this file
  10. Analyze
    • Quickly do a static analysis of your code
    • Built in
  11. Handy shortcuts to extract an expression to a variable/method, or class
  12. Variable name guessing mostly works
    • If you assign a method to a variable for example
  13. Bind constructor parameters to fields
    • And create getters/setters on the fly
  14. IDE Chat: Quickly send code pointers to your team mate
    • Based on jabber
    • Worked out-of-th box, no need for a jabber server
  15. SQL Editor: Run SQL to:
    • Surprisingly good
    • Tools like SQLDeveloper are needed only occasionally
  16. Code folding using anonymous classes
    • Almost feels like closures (#prejdk8)
  17. Encoding Support: – Properties (native to ascii)
    • no \u…
    • Notices you if the encoding of your file is wromg
    • Helpful info in the statusbar (a little small though)
  18. Deployment
    • Run script beforehand or after deployment
    • Possible to manually tweak artifacts
  19. Server Support
    • Set PATH variables
  20. Structural Select (Ctrl-w)
    • Do complex search and replaces
  21. Fun!!
    • Yes experimenting with IntelliJ was fun
    • Less cursing than eclipse
  22. Add Missing Switch Branches
    • When using enums
  23. Very good diff tool
  24. Fast svn updates via patches
  25. Fullscreen Support
  26. Darcula Theme
    • I like it, some don’t
  27. AspectJ Support
    • Show active aspects of a method, or related methods to an aspect
  28. JPA Support
    • JPA console (Send JPA queries, to the DB)
    • See connection of JPA class to DB table (complains, if theres is none)
  29. XML Editor
    • Very good XPath support (Show XPath of this node, apply XPath on document)
    • XML Refactoring
  30. Refactoring Support für POMs
    • Looks for changes in other pom-files
  31. Emmet Support

Devoxx 2013 Recap


Finally I managed to visit Devoxx. I had a great time, attended many good talks and as usual few not so good ones.

The most prominent topic was the upcoming JDK 8. Its most visible feature will be the advent of lambda-expressions. Which will have a deep impact on developers. Especially the collections-api feels whole new.

Second thing people talked about was, well, Javascript!  I kinda like Javascript, most devs don’t. But the things people do with node.js and friends seem to impress java folks. Angular.js and single-page applications (spa) was,  I guess,  the second most talked about topic on this conference. Google did do some pushing here and there. All in all there seem to be some resentiments against  spas. But all talks about spas I went to were packed, so there must be something fascinating about them. I would predict we will see a slight paradigm shift towards this architectural style.

The term reactive and the reactive manifesto was cited quite often and it fits into the aforementioned schemes. Though I was looking into the functional world recently, I didn’t quite grok the talk(s) about reactivity. Perhaps those were only bad sessions, but  I guess I have to get up to speed in this area.
Java EE 7 is here, but compared to JDK 8 it feels like a maintenance release.

Much talking about android, which I didn’t care about.

RaspberryPis everywhere! There seems to be quite some hype around those small thingys. Devs attach them to virtually everything. Duct taping them to drones, is the thing. I bought one, let’s see what happens ;)

There were some Spring talks, but compared to Java EE it seems rather irrelevant.

There wasn’t so much buzz around alternative JVM languages. It seemed like an accepted fact, that they have their place in the ecosystem, nothing too fancy about them any more. Use them if you like, nobody will get hurt.

I’d like to close this article with my personal top-five sessions:

Top 5 Sessions

  1. Autumn Collections
  2. Bleeding Edge
  3. Angular Workshop
  4. Projekt Lombok
  5. Groovy


Hibernate SequenceHiLoGenerator

Recently I digged a little in the mechanism of our ID generation.
One of our IDs was annotated like this:
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "myIdGen")
@SequenceGenerator(name = "myIdGen", sequenceName = "MY_SEQUENCE")
protected Long id;

But seemingly the underlying (Oracle-)sequence remained untouched.
On an empty DB, with a sequence value of 1, the id that was returned by:
Serializable id = this.getHibernateTemplate().save(domainObject);
was 50. Strange! I would have expected: 1.

The Logfiles then hinted me, that Hibernate chose the SequenceHiLoGenerator for ID Generation.

Looking through the web here, here and here , I came  close to understanding the algorithm.

The idea is to not touch the DB everytime an ID is needed but to „reserve“ a block of numbers, using 50 as a default block size. Reservation is done by: 50*CurrentSequenceValue. Then Hibernate adds 1 to this base value everytime a new id is needed. When it has added 50 times, a new block is reserved using a fresh sequence value.

Perhaps this picture makes it clearer:

All of this configurable of course. I am a little surprised that this is the Hibernate default though.


JMS Fun in JEE Wonderland

Recently I had to dig into JMS to implement some asynchronous behaviour in our current application.
I haven’t used JMS thus far, but it looked quite promising and straightforward to me.
I got the ConnectionFactory and queues working quite fast and the first messages appeared in my queue. Horray!
To consume those messages I had to implement a MessageListener which looked something like this

name = "MyQueueListener",
mappedName ="jms/MyQueue",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")}

public class MyQueueListener implements MessageListener {

private IMyStalelessSessionBean myStalelessSessionBean;

public MyQueueListener () {}

public void onMessage(Message message) {
//Consume my message

public void IMyStalelessSessionBean (IMyStalelessSessionBean myStalelessSessionBean ) {
this.myStalelessSessionBean = myStalelessSessionBean ;

Looked quite ok to me, deployment on the Weblogic server went well. So I should be ready to rock!
But, after I put something meaningful in my queue, onMessage() was not called, instead I was greeted by:

#### <> <> <> java.lang.IllegalArgumentException: argument type mismatch.
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.bea.core.repackaged.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:121)
at com.bea.core.repackaged.springframework.jee.inject.MethodInjection.apply(MethodInjection.java:47)
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.applyInjections(Jsr250Metadata.java:233)
at com.bea.core.repackaged.springframework.jee.inject.Jsr250Metadata.inject(Jsr250Metadata.java:218)
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.injection(EjbComponentCreatorImpl.java:131)
at weblogic.ejb.container.injection.EjbComponentCreatorImpl.getBean(EjbComponentCreatorImpl.java:74)
at weblogic.ejb.container.manager.BaseEJBManager.createNewBeanInstance(BaseEJBManager.java:216)
at weblogic.ejb.container.manager.BaseEJBManager.allocateBean(BaseEJBManager.java:233)
at weblogic.ejb.container.manager.MessageDrivenManager.createBean(MessageDrivenManager.java:286)
at weblogic.ejb.container.pool.MessageDrivenPool.createBean(MessageDrivenPool.java:165)
at weblogic.ejb.container.pool.MessageDrivenPool.getBean(MessageDrivenPool.java:90)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:434)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:371)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:327)
at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4072)
at weblogic.jms.client.JMSSession.execute(JMSSession.java:3964)
at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4490)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)

IllegalArgumentException while calling onMessage! WTF! I was quite lost!
Tweaked the @MessageDriven-annotation and doublechecked the correct signature of onMessage. But no success!
After a while I set an ExceptionBreakpoint for IllegalArgumentException and found myself in the middle of JEE internals. Reflection all the way!

Eventually I found the culprit:
The stateless session bean I wanted to be injected seemed to be null.
Removed that code temporarily. And bang! onMessage was called. After fixing the injection everthing worked well.

But to cut a long story short:
What does an IllegalArgumentException do to help me under that circumstances. My mistake had no obvious connection to the onMessage-method.
Something more meaningful would be highly appreciated and would have saved me a lot of time.
But still it is always a little fun to me, to finally get my head around something like that ;)

EclipseCon 2011 Session proposed

I managed to propose a session for the EclipseCon 2011 conference the last minute.
The talk will deal with ouir experiences while implementing a Rich Client based on Eclipse RCP.
The decision if it will accepted is announced on September, 1st. So keep your fingers crossed. I am excited already! And a little nervous ;-)
Here is a link to the proposal.

Eclipse RCP: What to do when things don’t work on your colleague’s machine

I have compiled a list of potential pitfalls, that one might step in when executing code on another system:

  • Check your IDs
  • Check them again
  • Does your product contain all nessesary Plugins/Features
  • Does your run-configuration (the one generated by selecting Run on your product) contain all your plugins? Did you press Add required plugins
  • If you use features, check them! Are all plugins present?
  • Help system: If your help system does not show: Double check that the Plugin-Editor did not swallow your context definitions. They are often gone if I simply open the editor. Topics do not disappear…
  • Check if all help system dependencies are present in your run-configuration. Start by adding all *help*-plugins, continue with *jetty* and *servlet*. Then press Add required plugins. That should do the trick.
  • If you know of any other helpful tricks, please let me know!