The following blog article summarizes key issues I found interesting when you consider one of those technology stack options. I will not try to convince somebody to choose either of the two. It’s the decision making process and the key arguments that are important to me and that I want to share.
- for him a standard is something that is established, accepted and dominant
- following this definition only some of the Java EE APIs like the Servlet specification can be considered as a standard, because they are widely applied in the Java production technology landscape
- he looks in the past saying that there was little investment protection in some of the Java EE Standard APIs, like for example the EJB specification (massive API changes over the last decade)
- he also claims that JPA and JSF in their 1.0 Versions weren’t sufficient to fulfill the technical requirements in large scale enterprise development projects
- he looks at CDI as another young standard that needs to proove a long term stability before it can be considered as a standard IOC mechanism in Java enterprise applications
- consequently, his conclusion for the moment is: Sping and Hibernate are still “the de-facto” standards for Java enterprise development
The lessons of these phase make their way into the subsequent API versions and therefore – for a while – the API gets instable. Functionality is added, APIs are reduced adopted, simplified and so on. This turbulent and uncertain storming phase leads to increasing migration costs if customers want to follow the standard. Even if the 2.0 Version is downwoards compatible, using the nice new features instead of the many workarounds means refactoring efforts. If the API is not downwoards compatible API changes enforce migration effort, there is no choice. After a while however the API gets mature and these refactoring costs decrease, the API entered the phase of stabalization.
A mature API has constantly low costs of migration and refactoring because no fundamental changes are applied. After a while a technology is not used anymore, because it’s replaced by other innovative APIs. The technology is dead – there is no investment anymore in these APIs, the community stopped the project. Image 1 shows the idealized API life cycle.
|Image 1: Idealized life cycle of Java EE APIs|
This wrapper is used as API to build the business applications. The wrapper API could be the Spring Framework, or your own set of custom framework APIs. This way it’s easier and more efficient to make required changes when we moove to new application server releases or Java EE versions respectively. The wrapper absorbes Java EE API changes and saves us from the burden to change 50 applications. Instead, we do the changes once in a central place. Our development groups are not affected by application server upgrades. OE suppliers and the Java Communication Process (JCP) do not influence our decisions and efforts.
I am saying your own set because you may use a mixed technology stack (Image 2): some mature Java EE APIs (e.g. Servlets, JPA 2.0), some de-facto standards (e.g. Spring IOC) and some proprietary custom APIs that you have developed as wrappers around Newby Java EE APIs. The most important thing is that those APIs support downwoards compatability for your production applications. You have to find a set of APIs that saves you from large migration efforts when you want to move to new Java EE application server releases.
|Image 2: Mixed technology stack for Java enterprise development|
The answer is: because someone had the courage to use it and others (including Java EE) followed. A “standard” is what a large part of the community uses to run large applications in production. A standard is not necessarily a Java EE standard. In the past Java EE standards followed the de-facto standard frameworks (e.g. Hibernate, Spring). There is a high probability that any new technologies first reach a certain level of maturity in open source frameworks. Then they will become Java EE standards. That’s because the vast majority of Java technology innovation has its source in the community – at least for the last decade.
Reference: Java EE 6 vs. Spring Framework: A technology decision making process from our JCG partner Niklas.
Related Articles :