Over a million developers have joined DZone.

A Personal Opinion on the Future of Jakarta EE

DZone's Guide to

A Personal Opinion on the Future of Jakarta EE

With Java EE officially named Jakarta EE, here is one dev's thoughts of the future of the specification and what it needs to do to thrive.

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

The following is just my personal opinion of where Jakarta EE may be going. I am far removed from the decision makers and this opinion is based on what I have read and my experience as a teacher. Feel free to label me a crackpot.

I began to teach J2EE in 2002. It was a mess. Most of my time was spent on explaining the purpose of the numerous XML files and the three strange beans, session, session stateless, and EJB. Of course, this was in the days when it was thought that programs will be frequently reconfigured via their XML files and that pooling the strange beans was the state of the art. When I got a copy of Rod Johnson’s book J2EE Development without EJB, I thought that the concept was intriguing. However, I was required to teach what was most commonly used in industry, and at that time, it was J2EE.

Fast forward to today and much of what Rod rallied against and that led to the creation of Spring has changed. While some may disagree, I find Java EE 7 easier to use and easier to teach than Spring.

All hell broke loose last year with the much-delayed release of Java EE 8. Components that we were looking forward to were dropped. The IDEs were slow to upgrade to Java EE 8. Then came the bombshell that Oracle was going to drop their stewardship of Java EE.

The Guardians came into being just before the release of Java EE 8, when Oracle announced that it was dropping certain popular new components. While I could speculate why Oracle did this and complain bitterly, there is nothing to be gained. Oracle controls the destiny of Java and as a corporation, they will make decisions that have a positive effect on their bottom line. I can only assume that the expense of maintaining and promoting Java EE was no longer cost-effective. The money invested in Java EE could be spent in other areas that offered the company a higher rate of return.

Oracle then began to either donate and/or make fully open source different parts of their Java portfolio. NetBeans went to Apache and Java EE went to Eclipse. Fortunately, the word Java is not in NetBeans, so it kept its name. Java EE needed to be rebranded for no discernible reason. There was much written on this, but in the end, it turned out to be nothing more than a distraction. It also ignored the real issue.

Java EE is a full stack development environment for enterprise level applications running on an application server. It was promoted as such and Oracle had evangelists traveling the world to get that message out. That ended abruptly when the evangelists were all let go. I was disappointed because I thought once I retired from teaching, I could become an evangelist. That was also the point in time when Java EE began its slow death march inside Oracle.

Apache, Eclipse, and other open source foundations do an amazing job at ensuring that the software that falls under their umbrellas is engineered to the highest standards. What they don’t do effectively is promote or evangelize their portfolio of software. Don’t get me wrong, I have seen Eclipse at conferences, and I will be submitting proposals to an Apache Con coming up in Montreal soon. That is not the sufficient level of promotion that Java EE needs.

Java EE is not without its cheerleaders. Red Hat, IBM, and Payara, as well as some others are actively out there promoting Java EE, but none have the gravitas that Oracle, the home of Java, had. In my myopic view of the world, Spring has managed to convince the enterprise development community that Java EE is nothing more than the necessary support libraries for some aspects (sorry about the AOP humor) of Spring.

What does this all mean for Jakarta EE? On the plus side, now that it's fully open source, many more interested developers will be able to contribute to its various components. On the minus side, I fear that a clear vision of what Jakarta EE is will be lost. Communities will coalesce around specific elements for their own self-interest. Self-interest is a good thing. What I believe will be lost is a vision of Jakarta EE as a complete and integrated system to be considered alongside Spring or Vaadin. I worry that Jakarta EE will become another Commons style library.

That was a depressing conclusion. What can be done? I am way out of my league on this. I can only speculate that we need one of the existing corporations or the creation of a new one to put Jakarta EE on the same playing field as the frequently mentioned Spring. Spring is an excellent framework, and I have taught Spring, but it’s a different product from Jakarta EE. Spring is also backed by the deep pockets of Pivotal, who are in turn backed by the enormous pockets of Dell. An obvious choice for a corporation to step up is Payara, who promote their working version of Glassfish. Whomever it might be, I wonder if there is the necessary investment available to return EE to its status as a true enterprise stack.

For the past three years, I have attended parties at Bain Capital while at JavaOne. They have a wall with the names of all the companies they have invested in. A company that leads the commercialization of Jakarta EE should be on that wall alongside Twitter and others. To the investors out there, I will happily provide you with my mailing address to send me the checks.

Anyone want to start a business or hire a 64-year-old evangelist?

One final word concerning the Java EE Guardians: It came into being because it was felt that Oracle was not listening to the developer community. With the donation to Eclipse, I am uncertain what the raison d’être is of the group. Reza Rahman has done an amazing job in rallying the EE community to get their voices heard. Now I think we should all join the Eclipse Foundation and directly influence Jakarta EE. We need to make noise inside Eclipse rather than outside.

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat

java ee ,java ,jakarta ee ,enterprise development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}