Java EE and Spring

In the Java community, the battle between Spring and Java EE is an eternal topic. In this debate, preachers, architects and fans from two camps are sparing no effort to defend the dignity of the party and try to persuade each other to join their own camp, but the result is that it is difficult for both sides to persuade each other, and each has a good reason to make the right choice. There are architects involved in this debate who are responsible for the choice of the platform. So how do you think about the long-drawn spring vs. Java EE argument for the average developer?

Siva is a passionate Java developer, open source evangelist, well-known blogger who specializes in Java, Struts, Hibernate, spring and other technologies and frameworks. Siva has used both spring and Java EE, but he is neither a fan of spring nor a faithful follower of Java EE. Instead, he has his own understanding and knowledge of Spring and Java EE, and chooses the right technology according to the specific needs of the project. Recently, Siva shared his understanding and understanding of Spring and Java EE, hoping to help readers.

Business aspects

In many organizations, the choice of technology is not entirely the developer's decision. Specifically, if you work in a large enterprise organization, it is highly likely that a dedicated team of architects will be responsible for deciding what platforms, frameworks, and libraries to use in the project. In addition, large enterprises in the choice of technology platform will also consider the following aspects:

• Maturity of platforms, languages, frameworks, and libraries
• Business Support
• Licensing fees, etc.

As a developer, you may not be able to influence the decision making process in these areas, especially for developers who are in the offshore development center. Therefore, for developers, you may not need to focus too much on these areas.

If you are familiar with spring, then mastering Java EE is not difficult, and vice versa.

I'm very surprised that someone would say he's a Java EE expert, but he doesn't understand spring and vice versa. Whether Java EE or spring uses the same core APIs (Servlets, JPA, JMS, beanvalidation, etc.), the difference is what binds these things together, spring or application server.

While there are different APIs for Dependency injection (Spring DI, CDI), REST (Jax-rs, SPRINGMVC), they behave very similar to each other. One might say that CDI is better at type safety than Spring Di, such as:

• If there is only one SPRING/CDI Bean, then using @autowired or @inject is no problem.
• If there are two spring or CDI beans implemented, the injection fails and throws an error, saying "More than one injected object has been found."
• You can implement a custom bean provider by using @produces or @bean annotations.

As long as they behave similarly, I don't care whose implementations are more type-safe, and who uses string-based mappings in internal implementations. What I'm trying to say is, how could someone be a spring expert but not understand Java EE, and vice versa. How long does it take a spring expert to master Java EE?

Which one of spring and Java EE is more friendly to developers?

I think so far, many developers should be able to recognize that the success of a technology is not entirely dependent on their own strengths and weaknesses, but also depends on the developer's usage rate. The important thing to know is that "not every software developer is a star developer, there are many middle-level developers." In order for people to be able to use a certain framework or technology, the framework or technology itself is tailored to the needs of this segment of the population. I think spring is doing very well in this area, and it provides tools such as spring Boot, user guides to help developers get started. The spring Security, Spring integration, Spring XD, Spring social and other projects all work well to address the needs of the business. In addition, spring offers a variety of templates that allow people to easily get started without having to write a lot of boilerplate code.

Java EE also helps developers get started with tools such as JBoss Forge, Wildfly Swarm, and more. In addition to Picketlink, I can hardly see what Java EE Frameworks provide security solutions, but even picketlink, I think, is too complicated. I would like to express the view that "what spring can do, Java ee basically can do." The difference is which one will provide out-of-the-box support for ordinary developers.

Lack of context of controversy

When the spring camp and the people of the Java EE Camp started arguing, there was no end to it. Unfortunately, the debate often revolves around meaningless or outdated points, such as the following:

Extensive use of XML

Java EE fans start by saying that Spring uses XML a lot, and I hate XML. If you're still using a version of Spring 2.5 and you think spring is full of XML, then I want to say you wake up and see Http://spring.io.

EJB and JSF are garbage

Spring fans will bash EJB and JSF as if they were EJB 2.x or JSF 1.x. If you look closely at the EJB 3.x and JSF 2.x, then they will not have this idea. Don't look at the current EJB 3.x with ejb2.x's old eyes 6 years ago.

Heavyweight and lightweight

The "heavyweight" here refers to the run-time situation. When you deploy managed beans to a Java EE container, the container generates proxies for it and injects all of the Enterprise Services (transactions, security, and so on), which are implemented by spring AOP for spring. There is no way to decide which is more heavyweight, container agent, or spring AOP agent, but I think the difference is not too great. Some people will use the deployed War packet size as a basis for judging whether it is "heavyweight". In this case, the difference between the Java EE application Server + War and the spring app + 126 jar is obvious.

Vendor lock

I think it is important to choose a platform that does not depend on a particular vendor, but it is not appropriate to choose a platform purely on the ground that it can be migrated to another implementation. Can you imagine how many chances you have to migrate from one server to another? Choosing a platform without locking to a vendor is a "icing on the cake" behavior, but it should never be a key factor.

We don't need an external library

This is called "arguing for the sake of argument". Show me which application doesn't need other dependencies? If you say you want to develop your own log library, write your own HTTP client, develop your own general-purpose library, then I can only say that such developers are wonderful, put out of the box, but also to "reinvent the wheel."

You're using x now, you should move to Y.

I have found that many community sites have this view, especially in Reddit. When someone issues a post about Java EE and spring, there are two people who are involved and attack each other because they are not using their favorite platform. Think about it, if spring is rubbish, then how can there be so many people to use and like it? If Java EE is not good, then why would anyone migrate from spring to Java EE? Each platform has its strengths. All you have to do is respect the others. If possible, ask them why they choose this platform, is there a reason you do not know in it?

As a passionate Java developer, I really hope to find something I didn't know before about the debate between Java EE and spring, such as "in which case spring is more appropriate than Java EE, and in which case Java EE is better than Spring". I hope that spring and Java EE will be more than enough to form a healthy competition to make themselves more and more good. In this way, whoever wins the competition ultimately benefits the vast majority of developers because they have a more powerful platform. The original address is: http://www.infoq.com/cn/news/2015/07/spring-javaee

From for notes (Wiz)

Java EE and Spring