At first, it was Java, and there was Java Community Process, the procedure in accordance to which all revisions take place, and new versions of Java itself and related specifications come out. For example – Java EE and its components.
I must say, JCP is still that clumsy and bureaucratized system. Moreover, it is built on democratic principles: individually, anyone can join the JCP for free. If to speak about companies, it is paid. Vote on all the essential and not so java related decisions.
Java is a pioneer in a mass of different directions. So now, of course, it’s nice to scold JCP for a bunch of wrong decisions made. The problem is that at that time there was just no experience with such choices, and someone had to be the first. An example of such a wrong decision is the EJB 1.0 and 1.1 specifications, which were told gloomily in Wikipedia: “It was developed in 1997 by IBM and later in Sun Microsystems (EJB 1.0 and 1.1) in 1999.” In short, the guys from JCP did not know how to make large Enterprise projects (and no one at that time knew how to do it!). But here the guys from IBM (by the way – one of the executive committee of the JCP) came and said: “We know how to do it.” And in the non-transferable IBM style, they wrote a specification.
As a result, Java EE has its crucial element, which is EJB. However, EJB had its advantages: automatic, right out of the box, scalability by supporting application server clusters, again, authorization support from the table and, most importantly, it was the standard!
The result of the emergence of the first EJB were two things. First, the terrible HYIP in the java-world: “Now we will conquer the world. We have powerful EJBs! “Honestly, in those years there was a lot of hype in the Java world. In general, I want to note that if you have been in IT for more than ten years (and preferably 20), then you can see that the HYIPs are repeated with a precise cyclical nature. For example, modern HYIP on the Front-end is already the third. And I know exactly how it will end (a spoiler – a return to an ultra-thin client).
Now let us talk about Spring. Therefore, Spring was a small, beautiful, and enjoyable library. Yes, there were no annotations yet (they were added later – already in Java 5), all configuration consisted in editing the XML file. However, it was alone! It had a simple and clear structure à la web.xml and compared to the horror of the Java EE configuration files of that time, and it was just a darling. It took quite some time, and the presence of Spring on the project has become merely mandatory.
Let us have a closer look at Spring and J2EE stacks. The request is processed by the JSF page and then by the bean. Management goes further into business logic in EJB, which works with the database through JPA. So far, everything is simple and clear. The most pleasant thing in this whole picture is that if the load on this application increases by several orders of magnitude, then its scheme will not change at all. The app will need to be installed only on a cluster of several powerful nodes, and everything will work in a cluster environment without any changes. If the power is still not enough, it is enough to add another node to the cluster – that’s enough.
It is because of this solution on the Java EE stack that I recommend to use in cases where the scaling issue for your application is the most critical.
A simple application on the Spring stack is not very different from Java EE. The only difference that should be voiced right away is that a Java EE application can work in general only within the Enterprise Application Server (I remind you that Tomcat is not), and a form on the Spring stack can work on anything (on the same Tomcat) and even without a server at all (as it will launch it inside itself). It makes Spring stack ideal for implementing elements of the microservice architecture but at the cost of not supporting all the capabilities of the application servers. In general, a cluster application is not about Spring, and the scaling for Spring applications should be addressed separately. In most cases – significantly more expensive.
I must say that JCP did not become jealous of the upstarts for success and selflessly began to squeeze support for Spring IoC into the Java EE stack. And everything was beautiful spinning. All those who wanted (to be honest – in general, everyone) used Spring IoC in their projects, not paying attention to what the plan was written on.
The JCP committee in the JSR 244 specification: The Java TM Platform, Enterprise Edition 5 (Java EE 5) defined a set of JSR specifications that are included in the Java EE platform. The task of the JCP committee is to issue specifications based on which the Open-Source communities, as well as commercial organisations, create implementations. The Spring Framework is not an implementation of the JSR specification and, therefore, is not included in the list of standard JEE technologies.
The Spring Framework is used to develop Java / Java EE applications, so it becomes part of the Java EE application but is not a Java EE technology.
Using, for example, the standard Java EE implementation of Enterprise JavaBeans (EJB) technology provided by the BEA WebLogic application server, you can transfer your application to the Apache Geronimo server, and thereby use the Apache EJB implementation, which may be more productive or not contain significant errors. If you use the Spring Framework, you always use one application from SpringSource during migration, and if it includes substantial errors or does not satisfy you with other criteria, you have either to correct the mistakes yourself, or look for workarounds, or abandon this framework.
This article only indicates the ideological flaw of the Spring Framework, as in practice, the Spring Framework is successfully used to develop applications of varying complexity. Also, with this article, I do not belittle the advantages of EJB technology, which can also be successfully used.
Conclusion
- Do not try to make all the applications on anyone stack – they are intended a bit for different things. However, we must clearly understand why each of the stacks fits better. Simply put, Java EE – for an easily scalable monolithic application, Spring – for minimal applications with a GUI on the Front-end or microservice architecture.
- Do not forget that AJAX is now essential. If you plan to make a severe application on SpringMVC + Thymeleaf – get ready to lose development time. Writing AJAX with your hands is painful. So either React / Angular (fashionable, beautiful, youthful!) or the old JSF + PrimeFaces. Not so cute, but also quite nothing and without Front-ender. Note that it is for back-office applications (any admins, etc.) that PrimeFaces and their counterparts offer an unlimited number of ready-made business components, such as calendars, color picks, time zones, and all that. You will significantly increase your development speed.
- Your programmers may not know the Java EE stack. As my practice has shown, they learn it very quickly.
- And last but not least. I think the pendulum that once brought Spring to the top can go back to Java EE and throw Spring down. I would not rule out such a possibility.
[“source=javatutorial”]
