SivaLabs

In the Java community, Spring vs. JavaEE is a never-ending debate. In such debates, people form two groups consisting of evangelists, architects, and hardcore fans of one platform and debate endlessly. Those who participate in the debates may be architects who are responsible for platform selection. But what would developers think about this Spring vs. JavaEE debate?

I am a Java developer who uses both Spring and JavaEE, and I am not part of the Spring or JavaEE fan club. Here, I would like to share my own thoughts on this epic Spring vs. JavaEE debate.

1. Business (sometimes political) Aspects

In many organizations, technology selection may not completely depend on the developers’ choice. More specifically, if you are working in so-called giant enterprise organizations, there are high chances that there is an Architecture Team that will decide what platform/language/framework/libraries to use in the projects.

In addition to that, large enterprises also consider the following aspects while choosing the technology platform:

• Maturity of the platform/language/framework/libraries
• Commercial support
• Licensing cost, etc.

As a developer, I can hardly influence the decision-making process for any of the above aspects, especially when I am a developer in an offshore development center. So I don’t worry too much about these things.

2. If you are really good at Spring/JavaEE, then learning the other one shouldn’t be difficult

I am always surprised when someone says, “I am a JavaEE expert, but I can’t understand Spring,” or vice-versa. Both JavaEE and Spring work on the same core APIs (Servlet, JPA, JMS, BeanValidation, etc.); the difference is who is gluing the things together, Spring or the AppServer.

Even though there are some different APIs for things like dependency injection (Spring DI, CDI), REST (JAX-RS, SpringMVC), etc., they look and behave pretty similarly to each other.

Maybe someone can say CDI is more typesafe than Spring DI. Doesn’t Spring and CDI behave similarly when:

• Injection using @Autowired or @Inject works fine if there is only one Spring/CDI Bean.
• Injection fails when there are more than one Spring or CDI bean implementations by throwing errors saying, “Found more than one eligible bean that can be injected.”
• You use @Produces or @Bean annotated methods to provide custom-made objects as bean providers.

As long as they are behaving similarly, I don’t care whether they are implemented in a more typesafe manner or use String-based mappings in their internal implementations.

How can one be an expert in Spring and not understand JavaEE, and vice-versa? How much time can it take for a Spring expert to learn JavaEE?

3. Which is more “Average Joe developer” friendly

I think by now many people should have realized that the success of a technology may not completely depend on its merits, but also on developers’ adoption. The most important thing to realize is, “Not every software developer is a rock star developer. There are more average joe developers than passionate tech ninjas.” So, in order for people to adapt to any framework, it should be “Average Joe Developer” friendly.

I think Spring is doing a pretty good job at it by providing more tools like Spring Boot, User Guides, etc. Spring Security, Spring Integration, Spring XD, and Spring Social address modern business needs very well. Also, think about the various templates provided by Spring that make it easy to do things without worrying about boilerplate coding.

JavaEE is also doing very well by introducing JBoss Forge, Wildfly Swarm, etc., to quickly get started. I came across a few JavaEE-based frameworks like PicketLink, which addresses Security requirements, but I felt it is much more complex than it should be.

The point I am trying to convey is, “You can do pretty much everything in JavaEE that you can do with Spring.” The difference is which one is giving more out-of-the-box to the average joe developer.

4. Lame arguments without context

Whenever the Spring vs. JavaEE debate arises, people form two groups and debate endlessly. Unfortunately, the debates focus on some useless or outdated points.

XML heavy: JavaEE fans first start by saying Spring is XML-heavy, and “I hate XML, blah blah blah.” If you are still using a version of Spring older than 2.5 and assuming it is still the same XML-based framework, then my friend, you should wake up and head to http://spring.io.

EJBs are bad (or) JSF is bad Spring fans jump on to bashing EJB and JSF as if they are the same as EJB 2.x or JSF 1.x. If they really look at EJB 3.x and JSF 2.x, then they wouldn’t argue about this at all. Don’t judge EJB 3.x with your 6-year-old EJB 2.x experience.

Heavyweight or lightweight My interpretation of this ‘weight’ thing is based on runtime footprint. To my knowledge, when you deploy your managed beans into a JavaEE container, the container will proxy it and inject all enterprise services (Transactions, Security, etc.), and in the case of Spring, it will be done by Spring AOP. I don’t have any metrics to say which is more heavyweight, the Container Proxy or the SpringAOP Proxy, but I guess there may not be a significant difference.

Some people consider the size of the WAR file as its ‘weight’. In that case, compare the (JavaEE AppServer + war) size with a (SpringApp with 126 jars) and see which is lightweight. 🙂

JavaEE is standards-based Come on, guys!

Vendor lock-in I think choosing a platform that doesn’t make you stick with one particular vendor is good. But going with an option purely based on the ability to move to a different implementation is not correct. How many times in a year do you switch from one server to another? Choosing a platform that doesn’t lock you with a vendor is a ’nice to have,’ but it should not be a major factor in choosing your platform.

We don’t need external libraries This is called “Arguing for the sake of arguing.” Show me any real application without any dependencies. If you say, “I will develop my own logging library, I will write my own HTTP client, I will develop my own common-utilities,” then you need to look for a slightly more lazy architect/developer who doesn’t have the “Re-invent all the wheels” sickness.

5. Don’t look at the crowd and say, “You are all idiots because you are using X; you should migrate to Y.”

This is a common pattern that I observe on many community sites, especially on Reddit. Just post anything related to the JavaEE vs. Spring thing, and there will be two groups who bash the other group like anything because the other group is not using their favorite platform.

Think for a minute. If Spring is not any good, why do so many people use it and love it? If JavaEE is not good, why do so many people switch from Spring to JavaEE? There are so many good things in each platform. Respect others for choosing whatever option they choose. If possible, ask them the reasons why they went with one over the other and learn if you missed anything.

Just saying, “You all are idiots for not using my favorite option,” doesn’t make them use your favorite technology. In fact, it triggers the thought to come up with a list of points why your favorite platform sucks.

If you really want them to switch to your favorite platform, then show the reasons with code examples. Show them how easy it is to develop applications using your favorite platform with sample applications. Write more articles on commonly faced issues and how to resolve them. Get the “Average Joe Developer” on board with your favorite platform.

As an enthusiastic Java developer, I read the Spring vs. JavaEE discussions, hoping there might be a few things I don’t know, such as “in which areas one is better than the other.” But I find 70% of the discussions go on lame arguments, which is not very interesting to me.

I wish the Spring and JavaEE camps would fight more and more and make their platforms superior to the other. At the end of the day, no matter who wins the debate, developers will ultimately have more powerful platforms.