For once, this article will not show you any line of code or any demo application.

Today we discuss about architecture and the recent trend in the Java (and more specifically Spring) world for abstraction and over simplification.

I Magic is everywhere

• Have you ever used the @Transactional and @PersistenceUnit/@PersistenceContext annotations in your applications ? Do you really know what happen under the hood (apart from what is said in the official documentation) ? Did you know that when used together with an @Transactional annotation, the @PersistenceContext will get an instance of EntityManager from a thead local ? If you answer no to one of these questions, you are relying on magics without knowing how it works (check my previous article about @PersistenceContext/@PersistenceUnit for in depth details)

 

• Do you know which beans are created and configured under the hood of the <mvc> namespace ? A guy already asked a question on a Stackoverflow thread about this. As many folks he uses the <mvc> namespace without really knowing what is done under the hood and one day he’s stuck when he tries to get rid of it.

 

• What do you think about Spring @Controller and @RequestMapping annotations ? Cool stuff right ? But when you face a big project with many controller classes developed by different people and embedded in different jars (an extreme case I confess), how can you have a good overall view of all URL paths ? A guy faced this issue and asked the question again on Stackoverflow here.

 

• Do you know how flexible parameters for @RequestMapping methods are achieved in Spring MVC 3.1 ? Do you know that you cannot have a Model map as parameter for an @ExceptionHandler method although the official documentation let you think so ?

 

• Do you know how to inject a custom filter or to plugin a custom behavior in the Spring Security filter chain with the Spring Security namespace ? Are you able to configure the whole filter chain by pure XML configuration ? (some help to do this here)

 

• One day a guy in my office came and asked for some help to set up a multi-channel JMS queue. I advise hime to emulate virtual queues using JMS selector but he was totally stuck because he used to work with the Spring Integration namespace and did now know how to fine tune a JMS message listener to use selector.

For each of the above situation, we’re are dealing with magics. What is cool with magics is that it makes your life simpler and easier. Magics helps you to bootstrap a project very quickly, to focus on the functional design instead of wasting your time in technical configuration. Magics is just an additional layer of abstraction added on top of technical framework to help people “deliver value“. It’s perfectly inline with the “agility” trend.

In most cases (80%) all these statements are true. But if you dare to stray from the main path of 80% use cases, you are a dead man unless you accept to dig in source code and spend hours (if not days) to understand the underlying logic.

 

II Understanding the magics

The idea of my talk is not to bash magics (also called convention over configuration) but to remind you that the key rule in this world (and mostly in the IT world) is: you must understand what you are doing. Too much abstraction can be dangerous. Reading an online tutorial to implement a solution is far from enough, you must also understand the underlying technology.

• Using ElasticSearch is great, understanding (not necessarily in details) how Lucene works is better
• Mastering SQL queries is good for your CV. Understanding how execution plans are built, how indexed are created and used will leverage you skills
• Knowing Hibernate is good, understanding how SQL works behind the scene is best
• etc…

At Devoxx France, Neel Ford gaves a talk on Abstraction Distraction where he emphasized that we must be aware of too much abstraction and do not let it distract us from the real thing, the real technology behing the scene.

 

III XML is not bad!

XML was very trendy during the last decade. At that time, during a job interview, if you did not know what is SAX/DOM, XSLT, XPath and all of the kind you got no chance being hired.

Nowadays the hype has changed, XML & XML-based Web Services is being criticized, sometime for good reasons, for its verbosity, difficulty to setup, heavy weight etc. The new star for cross-application exchanges is the JSON format along side with RESTfull architecture.

In frameworks, the trend started with dedicated namespaces (Spring Security, Spring MVC) to alleviate the burden of configuration. Then they switch to Java annotations (Hibernate with Entity annotations, Spring & CDI with @Autowired & @Inject) and finally the idea for the next few years is full java configuration.

Do you remember how XML was sold to developers in the past ? They said that we must separate configuration (XML) from code (java). It helps the devops because they can fine tune the application with XML without having to rebuild the code.

Now with the full java config hype, we’re doing exactly the contrary, putting all configuration in the code !

One big advantage of XML is its centralization benefit. No matter in which package you put your code, no matter from which jar the classes come, all the instanciation and wiring are done in one big or some split XML files. With XML config you have a global overview of what is going on in your application, of what being injected into which bean and so on.

 

IV The future

It’s quite soon to predict what’s gonna happen in the next few years. The over-convention and over-abstraction trend is just starting. What I can say for sure is that step back from the hype and have good understanding of what’s lying behing the scene. Always stand out from the crowd and beware of the hype !