; last updated - 10 minutes read

The Java community moved to a new paradigm during the last five years, and nobody talked much about it.

Act 1: Programming

When I entered the enterprise Java world, every programmer did what was expected from them. They wrote programs.

Act 2: Configuration over Programming

Enter Spring. Or EJB before version 3.0, for that matter. Programming - they said - is bad. It's OK to write small modules, building blocks of your application that can be glued together. But the glue code needn't be code. It's better to adopt a declarative programming style. Design configurable modules, and configure them in XML. That programming model has great advantages: you can replace modules by different module as seems fit. Configuration gives you a big boost of productivity.

Plus, it can be done by everybody. You don't need highly-paid programmers for that. I remember an enthusiastic talk by a SUN speaker who tried to convince us every programmer team needs to cover seven roles. Luckily, I've forgotten which roles they promoted. It's a moot point, anyways: I've never seen the full-blown model implemented in a company.

Before long, the Spring world got lost in the XML hell. As Henk recently wrote on Reddit,

Spring initially wanted you to have 30~40% of your -code- in XML and refused to call it code, but always wanted to let you think it was -configuration-.

I had the same impression, too, and that's why I didn't adopt Spring before 2013. I didn't want to end up as an XML programmer who isn't even allowed to be called programmer.

The EJB (before EJB 3) world had similar problems. The configuration hell never became as apparent as in Spring because EJB < 3 had other problems that overshadowed the configuration problem. Do you remember the good old times when you had to write five classes and interfaces just to write one Enterprise Java Bean? The next version of EJB brought a big improvement: local beans. Which meant you had to write seven classes and interfaces. At the time, Spring was really a light-weight alternative, and that's why Spring is called a light-weight framework even today. A debatable claim: Spring-core alone weighs almost a megabyte, not to mention the vast Spring ecosystem.

Don't get me wrong: I really love declarative programming. But at the same time it's obvious declarative programming isn't the whole story. If it were, we'd all program in PROLOG. Plus, I doubt writing XML is declarative at all. Above all, it's error-prone.

Act 3: Convention over Configuration

Luckily the Java community is really clever. They came up with a great idea to solve the XML hell problem. It was called Convention over Configuration.

That was a big step forward. Even today, I'm fond of the idea. Define a small set of rules - typically naming conventions - and write a framework based on this rule set. Doing so allows you to drop most of your glue code. Pardon me - to drop most of your glue configuration. That's exactly the dreaded XML file. A small part of the XML file remains, but that's not a bad thing: the remainders are the interesting parts of the configuration file, the settings that go beyond simple configuration.

A couple of years ago I've introduced Convention over Configuration in our company framework. That's the same framework we've dismissed in the meantime because "nobody can afford to maintain a company framework". But the framework we've dismissed is still alive and kicking in the "legacy applications". I believe Convention over Configuration plays a crucial role in keeping these applications alive. It's easy to add something to our legacy applications.

By the way, "legacy application" is a horrible term in itself: I guess more often than not legacy applications are the applications that earn the company's money. Precisely the money is needed to write modern applications. Can't we find a more respectful word for this kind of application?

Act 4: Annotations over Convention

Did you hear anything about Convention over Configuration recently?

For what it's worth, I didn't. Convention over Configuration seems to have passed silently. It has been superseded by something truly superior: Annotations. Annotations are far from being new, they've been introduced in Java 5, but it took well into the middle of the Java 6 lifecycle until I felt the impact of annotations. But once it came, the wave was irresistible. Every framework - really every framework - started to introduce annotations. JSF could easily have adopted Convention over Configuration, but it skipped that step and went directly from XML to annotations.

Remember my rant about EJB < 3? Since EJB 3, we don't need to write seven classes and interfaces any more. One class does the trick as well. One class and a tiny annotation.

Convention over configuration may have been great, but it's nothing compared to the magic of annotations.

Annotations have become so popular that a co-worker of mine complains "annotations start to form a programming language themselves". This danger exists indeed. Many attributes of the classes I write are richly adorned with annotations. Sometimes you miss the attribute among all those annotations. There are JSR303 validation annotations, Hibernate annotations, Spring annotations, JSF annotations, AspectJ annotations, null check annotations, annotations to ensure preconditions and postconditions. And who knows what the future will bring?

Apart from that, there's nothing wrong with the new approach. Annotations are where the code is, and that's good: Annotations influence the behavior of the code. It has always been a bad idea to separate the static aspects of the code from the dynamic aspects.

Only - wait, what's the role of annotations? They configure the behavior of a class. Shouldn't we move that into a configuration file?

Obviously not. Many modern frameworks offer XML files as a fall-back mechanism. You can configure your program if you really need to (which is good). But it's hardly ever done. Most of the time we're happy with the default configuration.

Act 5: Programming over Annotations

Annotations are here to stay, but still... things are changing again. Programming is on the rise again.

Actually, the early signs of the renaissance of programming even predate annotations. I'm talking about DSLs. Domain specific languages are often introduced to configure a program. They are in the middle ground between programming and configuration. Some DSLs try to adopt the language of the users, some are specific to certain domains, such as testing. There are many different kinds of DSLs out there, but they have one trait in common: they add flexibility and ease-of-use to a program that's static and immutable. For instance, DSLs typically can be modified without recompiling the program.

Flexible languages such as Scala and Groovy allow for debuggable DSLs. Those DSLs are usually "internal DSLs", and aren't traditional DSLs at all: they are programs, written in a fashion that they don't look like programs. The general idea is business people can read the DSL without problems, and possibly even modify it. The flexibility of modern programming languages allows for that. Just remember Rod Johnson's famous executable poem written in Scala.

GUIs are a very fruitful field for DSL. I'll never understand why we all put up with XML for JSF pages. Why don't we write a DSL that's much more concise than the XML code? Plus, we can debug it, and even add logic. JSF introduces weird constructions like <ui:repeat /> which aren't really flexible. Wouldn't it be nice to use a for or while loop? And what about the expression language? Wouldn't it be nice to replace it with real Java code?

(Also see the comments below, where Rudy de Busscher defends the XML-based definition of JSF views. Rudy, you have a point: The current XML dialects also has advantages).

GroovyFX is a DSL that generates JavaFX applications. It's really powerful and simple. Obviously, we could easily write something like GroovyJSF - a Groovy DSL that replaces the XML files by something much more powerful. Consider this snippet of my chess program. It paints the chess board and the toolbar above the chessboard:

toolBar() { button(text: "flip board", onAction: { opponentsMove() }) button(text: "new game", onAction: { newGame() }) } group { 8.times { int column -> 8.times { int row -> imageView(x: 60 + 90 * column, y: 100 + 90 * row, onMouseClicked: { onClick(row, column) }) } } }

Notice the closures following onAction and onMouseClicked. They replace the JSF expression language, but in a much more flexible fashion. It's a real Groovy program, so you can do everything Groovy allows you to do.

Another interesting feature are the 8.times{ } closures. In Java, you'd write for (int column=0; column<8; column++) {}. In JSF, you are stuck. There's no equivalent to such a simple thing as a for loop. <ui:repeat /> replaces a for loop in certain circumstances.

Of course it would be easy to implement a <for /> component in JSF, but that's exactly the point: you don't have to go into such lengths in an internal DSL. It's just there.

The other example - the one that made me think and write this article - is Spring's Java Configuration. As far as I know, Hibernate's Java configuration is similar. Both replace the XML configuration file by a Java file that does the configuration. The big advantage is you can debug the configuration file. If nothing else, you can check whether the configuration is read at all, and whether the setting you want to have set are really set.

Ringing down the curtain

During the play we started from programming, went to configuration, from there to convention over configuration, spent some time with annotations and went on to DSLs and Spring's Java configuration. Which in turn is programming.

Each act of the game added some value. I don't want to miss declarative programming, annotations or - even if it went into oblivion - Convention over Configuration. I even see the value of configuration files (although these file virtually always cause trouble in production).

But isn't it interesting that programming - which has always been sneezed at as a necessary evil since the early days of UML, Spring and EJB - starts to become popular recently? Not even recently, if you count annotations as programming. But for some reason, nobody advertised it. Did the big consultancy companies who pushed SOA, MDA and XML with so much verve ever promote annotations? As far as I remember, it just happened. Annotations weren't big money. They worked just fine. Which was enough to make them a success story.

Imperative programming seems to have a raison d´être after all.

Dig deeper

The Chess GUI on GitHub (note that at the time of writing, the chess game engine itself doesn't work. But the GUI does).


Comments