Five Spring features that I miss in the Java Enterprise Edition (JEE) - codecentric ...


During the last years you could read a lot about the rise of the Java Enterprise Edition and the fall of Spring (a.k.a. Spring is the new legacy), only I don’t see it in real life’s work. For more than ten years I’ve been working on long time projects in very enterprisey companies like insurances and banks, most of the time providing common functionality to other developers, you know, in-company frameworks (if they are more strict) or just libraries. And for these kinds of libraries and frameworks I think Spring is still the best fit. I thought so before Spring 4 and Spring Boot came out, and now I’m even more convinced. In this post I’ll talk about five features I miss in JEE:

  1. JavaConfig
  2. Property management and the Environment
  3. Profiles
  4. Auto-configuration
  5. @Conditional annotations


In the context of company frameworks and libraries I definitely prefer a centralized configuration. It’s much easier to understand for somebody using the library what happens when you add it to your classpath. Autowiring and component scanning magic via @Named, @Inject and Co. may be nice for the actual application of the developer, but it’s not nice for a library the developer cannot know a 100%. And when talking about centralized configuration there’s nothing better than JavaConfig which can be easily found in every IDE even if there’s only a jar on the classpath, which can have a nice JavaDoc and so on. I’ve written about the advantages of JavaConfig before.

Property management and the Environment

Spring has always been strong in property management, importing property files and using properties in configurations has always been easy. Since the introduction of the Environment in Spring 3.1 it’s a pretty complete concept, with PropertySources reading properties from all kinds of sources, not only files, easily extensible via writing your own PropertySource, and using those properties in a consistent way. Default properties and overriding properties is also handled very well.


When writing a library for usage, it’s almost always the case that there are different environments in which it may run, these can be just different use cases needing a slightly different implementation, or different runtime environments etc. With Spring’s profiles it’s easy to define different configurations that only get active when a certain environment or use case needs them.


This one is new, and it’s from Spring Boot. It’s also extremely usable in enterprise environments. As a library / framework developer you may point to some configuration class in a spring.factories – file on the classpath (unter META-INF). If the user of the library uses the @EnableAutoConfiguration annotation, the configuration is automatically added to the user’s ApplicationContext. This way you, as a framework developer, can set up the ApplicationContext needed for your functionality, and the user of the library doesn’t need to do anything.
You may argue that’s basically the same if you have JEE annotations on your business classes and scan the library, but it’s not. It’s still a centralized configuration, which is much more suitable in enterprise environments, and you can do a lot more with it, as the Spring Boot guys are proving (for example starting an embedded Tomcat).

@Conditional annotations

As a framework developer you can have a lot of fun with these new annotations added in Spring 4 and Spring Boot. You may add certain configurations classes to the ApplicationContext only under certain conditions, here’s a list of some of the annotations: @ConditionalOnBean, @ConditionalOnClass, @ConditionalOnExpression, @ConditionalOnMissingBean, @ConditionalOnMissingClass, @ConditionalOnResource, @ConditionalOnWebApplication and so on. You see, you may add configurations depending on what’s on the classpath, you may add configurations just when the user added a bean of some special type, you may add a configuration only when the user didn’t add one of that type and so on. It’s a rich tool set for a framework / library developer.


I don’t know JEE as well as I do know Spring, so if you have some suggestion how to achieve those features above in JEE, don’t hesitate to comment. I’m eager to learn. But for the knowledge that I have today, my favorite for enterprise in-company frameworks and libraries is the Spring framework.
If you wanna know how we use those features to build a configurable, extensible, easy-to-use batch server with a lot of default functionality, take a look at spring-boot-starter-batch-web.