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


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.


  • Alex

    Hi although it would require a deep discussion about exactly if it would be a good addition or not in Java EE (JEE did never exists), I would like to say something about what your points:

    * About JavaConfig
    Well you can implement it without any problem using @Produces annotation. Of course it is not the same but pretty similar you can create a factory class with methods/attributes annotated with @Produces. You will get the same effect.

    * Profiles
    Probably you are talking about test environments, although again it is not the same, you can get the same by using alternatives or in case of testing probably you will be using Arquillian which your are the responsible of passing the required configuration files.

    In Java EE 7 you can set if you want to inject or not or even more complex using bean-discovery-mode. In this case I am not pretty sure if you can get the same result (I think so)

    So Spring is good yes of course but Java EE is advancing in giant steps mostly because now the open source community is behind it.

    • Tobias Flohre

      19. May 2014 von Tobias Flohre

      Hi Alex,

      thanks for your hints. I was aware of @Produces, but it’s not similar enough to JavaConfig, you still have to autowire the bean that is produced and don’t have a central configuration. Arquillian seems to be really nice, but the Profiles concept is not only for testing. I didn’t know about the bean-discovery-mode, but I’m not sure if you can achieve the same with it. Again, one of my main points is that you cannot have a centralized configuration in JEE.

      About “Java EE is advancing in giant steps”: that statement is too general for my taste. I heard a lot of general statements like “Spring is the new legacy”, “Spring brings no advantages over JEE”, “You have to migrate from Spring to JEE” and so on, and I would never state something general like that. You would have to take in account the full Spring eco system and the full JEE eco system, and you have to do that for every type of application. It’s just impossible. Instead, when I hear such statements, I get pointed to a presentation or blog post where somebody compares the simplest possible Spring MVC / Hibernate application with the simplest possible JSF / JPA application. Always makes me sceptical. Enterprise Java is much more than that… and I didn’t even start about Integration, Batch, NoSQL, Big Data, Microservices and so on.

      Anyway, you will agree with this one: successfully building an application is much more a matter of common sense than a matter of the underlying framework.

      • Alex

        In any case I am saying migrate to Java EE or Spring is dead, I am only saying that Java EE is taking giant steps into lightweight world and offer to developers a good set of API to build their applications. I have worked several times in Spring, but having a good knowledge about Java EE too makes me think clearly in a lot of cases which is the “best” framework in each case.

    • Tobias Flohre

      19. May 2014 von Tobias Flohre

      One more thing: I state above, that I prefer Spring over JEE, which could be a general statement, but I do it for a special use case: writing libraries and company frameworks. So it’s not that general anymore.


Your email address will not be published.