days
-1
-8
hours
0
-1
minutes
-2
-9
seconds
-3
0
search
The debate continues

Where is Java EE headed to? [UPDATE]

JAX Editorial Team
Java EE
Old style photo image via Shutterstock

Where does the future of Java EE lie? After Oracle reduced its activities concerning Java EE 8, community members created a group called „Java EE Guardians“. Then came MicroProfile, an open forum which aims to bring microservices to Enterprise Java. What’s next? We asked Java Champion Lukas Eder, Java Rock Star Adam Bien and Payara’s Mike Croft to comment on the current state of Java EE and its future.

Discussions about Java EE‘s future persist. After JAXenter launched its interview series with Java EE Guardians, people started a conversation on Reddit, so we decided to move it here and invite everyone to participate. 

Java Champion Lukas Eder

We asked Java Champion Lukas Eder to comment on the current state of Java EE, as well as on the rise of Java EE Guardians and MicroProfile.

JAXenter: Considering the current state of Java EE, do you think we need an initiative to protect its legacy?

Lukas Eder: That’s a very interesting open-ended question. And we can look at it from different angles (all subjective, of course). First off:

Do we need Java EE in the first place?

The Java EE “market” is big; a lot of companies (let’s call them companies) want to build “standard” software and a lot of infrastructure software vendors (let’s call them vendors) want to get a piece of the cake by selling “standard” software platforms (and/or services related to the “standard” platforms) to these companies.

These companies want to have as little cognitive friction as possible when going from one project to the next, but it is a poisonous thing to have too many choices in terms of technology. They pay the vendors to guarantee this lack of friction. Many companies get a free ride because many vendors offer the platform software for free as Open Source.

There is no Java EE standard.

Java EE evangelists used to like to paint a standards-biased picture where the UI framework market (often their favorite example) was shared mostly between Java EE’s JSF and Spring’s MVC. Of course, as the saying goes: “The only statistics you can trust are those you falsified yourself”. If you look at “the market” from a different angle, there’s also Angular JS which dominates it, probably much more than JSF and MVC combined.

We’ve had Struts, before that JSP (still the best Java web UI tech if you ask me) and before Java EE (and before J2EE), there were other technologies, and surely, in the future, there will be other technologies. And that’s just talking about UI frameworks. So, you can see that even within the “standards” scope there are a lot of choices — which is not surprising, given XKCD 927.

So, in my opinion, there is no Java EE standard. Java EE is only a recommended set of libraries that are guaranteed by Java EE certification to work together.

Therefore, the answer to the question do we need Java EE in the first place is “Yes.” However, this is the case only if said certification is your highest priority as an API consumer. Spring is an alternative to the Java EE “standards” where innovation and new features are added without too much of a formal process by a single vendor: Pivotal. They still add exactly the same value as Java EE to most customers, though. That value is: “It just works”. The difference is the following: there’s no certification, but trust in the vendor after many years of excellent delivery. And, there’s no competition in the implementation process because many APIs are proprietary Open Source.

Spring is an alternative to the Java EE “standards”.

Of course, if you build decent integration tests yourself, there’s a third alternative to Java EE and Spring. You don’t need either. You can choose any arbitrary set of third party libraries as long as you trust each individual vendor to “do the right thing” (which is often the case anyway, no matter if you’re using Java EE or Spring). For instance, if you’re using jOOQ (or Hibernate), you can use that library in a “standalone application”, in a Spring application, or in a Java EE application just the same.

Now back to the actual question:

Do we need a group like the Java EE Guardians?

If Java EE was a truly open standard (like HTML, or SQL to some extent), we wouldn’t be in the situation that we’re in. Oracle would just be one more stakeholder in a large consortium and it would be their own choice whether they withdraw from the consortium or not, without affecting the consortium as a whole.

Still, because of the way the JCP is organized, Oracle pretty much dictates what happens in the “standard”. For instance, the TCK for most aspects of Java EE are not open, freely available or even available without the need to accept very restrictive terms.

Should Oracle “secretly” want Java EE’s death, then that’s exactly what’s going to happen.

Now, Oracle seems to have lost interest in Java EE (although we do not know that for sure) and frankly they didn’t do an excellent PR job explaining their strategy. There is a lot of uncertainty in the industry with respect to the future of Java EE. Given Oracle’s tight grip on the legal aspects of Java EE, there can be no fork or truly open standard without Oracle’s consent. So, should Oracle “secretly” want Java EE’s death, then that’s exactly what’s going to happen.

I personally don’t think the Java EE Guardians can do a lot in this case. It’s worth trying, sure. The Guardians all have a big personal stake given the fact that their professional careers depend on Java EE. But as I explained above, there are non-certified alternatives like Spring, or random third party library collections that do the job just the same, so, perhaps, the best way to go forward is to create a new “Spring” from scratch that is governed by a true open standard consortium, free from any legal ties to Java EE, and with or without Oracle. Let’s call it … “Summer” (Note that the community just published “MicroProfile”, which seems to be an initiative which does precisely that.)

JAXenter: How could Java EE be brought forward? Should Oracle be convinced that they will get a better return from continuing to invest in Java EE? Should the focus remain on the community’s support? 

Lukas Eder: There was an interesting discussion on Reddit’s /r/java just recently. /user/thesystemx, who frequently comments on the subject, said:

At last Devoxx I spoke to several spec leads and people from Oracle, and they told me (off the record) that the direct licensing income alone is enough to run Java EE, and that excludes the tag on sales for related products.

And my first thought was…

The direct licensing income of a single Exadata installation is probably enough to run Java EE as well, so perhaps this is an order of magnitude thing (i.e. a “what’s this boring, irrelevant stuff over there stop wasting my time thing”)

As you can see, as a community, we can only speculate about what’s going on right now. I believe that the business is not interesting enough for Oracle. Plus, neither is the community because it isn’t Oracle’s. It’s Red Hat’s, Pivotal’s, IBM’s, and everyone else’s community. Oracle inherited a rather difficult legacy from Sun. Jonathan Schwartz (the former Sun CEO) testified in court in the Oracle vs. Google case that Java was “free”. Quoting from the Ars Technica series:

The strategy was, we agree on these open APIs, then we compete on implementations.

This is what an open standard does, and it was certainly Sun’s intention to “sell” Java EE as an (almost) open standard. But perhaps, after all these years. After doing some proper math, it just showed that this particular (almost) open standard provides benefits to competitors much more than to Oracle. Again, as we’re lacking official PR from Oracle, we can only guess. The fact is, we as a community cannot bring forward Java EE without Oracle. Oracle CEO Safra Catz made this very clear in the Oracle vs. Google lawsuit:

[…] And that Android was an unauthorized fork of Java.

This means that any unauthorized fork of Java EE will have the same fate as Android. Besides, I sincerely doubt that we can convince Oracle to give us more free lunch, so the future of Java EE is, without an actual statement from Oracle’s side, on hold.

Mike Croft —Java Middleware consultant at Payara

We asked Payara’s Mike Croft to comment on the current state of Java EE, as well as on the rise of Java EE Guardians and MicroProfile.

JAXenter: Considering the current state of Java EE, do you think we need an initiative to protect its legacy? 

Mike Croft: Work on Java EE has slowed, but it hasn’t stopped. The JCP involves more than just Oracle, though they are the biggest players at the moment. The Java EE Guardians’ focus is on getting some action from Oracle; their opinion is that this is crucial to the success of Java EE. I agree that movement from Oracle is important for the future of Java EE, whether that is Oracle working on the JSRs they lead or in relinquishing them to the community. It is important to remember that Java EE isn’t only Oracle, however, and there are a huge number of people and corporations of varying size which have a vested interest in its future. The Guardians group is just one effort of many and all efforts are needed in this, just as in any community-led project.

Java EE isn’t only Oracle, however, and there are a huge number of people and corporations of varying size which have a vested interest in its future.

JAXenter: How could Java EE be brought forward? 

Mike Croft: Java EE already has a way to move forward in the version 8 specifications. My personal view is that Oracle can still stand to grow their business by investing in Java EE. We have not heard any official, public response from Oracle as to their plans, so we can’t be sure that the lack of activity is permanent or only temporary as they put more resource into the “other projects” that has been noted on mailing lists. We, as a community, can’t stand still and wait for confirmation, though.

It’s this lack of knowledge which has driven Red Hat, Payara, Tomitribe, IBM and the LJC, who each have significant interests in Java EE, to announce microprofile.io as a way to bring about open collaboration. This is not an effort designed to exclude Oracle, but to leverage the incredible power of the wider Java community to address the needs of modern Java EE users. The aim is to iterate quickly and to collaborate openly on a standard. Standards are incredibly important in technology to avoid fragmentation and, from here, the future looks bright.

 

Java Champion Lukas Eder

JAXenter: Mike Croft said that the JCP involves more than just Oracle. What’s your take on that? 

Lukas Eder: That’s exactly how it ought to be, but for historic reasons it’s not true, and probably never will be. The JCP *is* Oracle, mostly, from a legal and operative perspective.

But Payara and the others who joined forces to create this MicroProfile initiative can create their own committee (as I’ve mentioned in my previous responses on JAXenter), which is truly open, governed by a foundation, not a corporation. There will still be politics, of course, but it would certainly help move this forward as the legal hurdles would probably be much reduced.

[MicroProfile’s strategy is to] catch up with Spring whose Spring Boot totally dominates the microservices hype.

JAXenter: Do you think MicroProfile is hoping for a reaction from Oracle?

Lukas Eder: I think that MicroProfile backers do not want to add more FUD to the debate. They thus openly invite Oracle to join. In my opinion, however, the strategy is to move forward with innovation and not wait for Oracle, but most importantly: to catch up with Spring whose Spring Boot totally dominates the microservices hype. If Oracle does decide to become part of MicroProfile, fine. But in my opinion, that would be rather surprising.

JAXenter: He also mentioned that “standards are incredibly important in technology to avoid fragmentation”; you said there is no Java EE standard. Why are your viewpoints so different?

Lukas Eder: Of course he says that. He couldn’t run Payara and not have this opinion :).

And I don’t fully disagree with Mike. What I mean by Java EE is not a “standard” is this: There are good, “obvious” standards and less good, less “obvious” ones.

A good standard is a standard that removes fragmentation where fragmentation creates friction, overhead, bureaucracy in the market without adding any value. Good examples for good standards are:

  • Electric voltages
  • Electric outlets (I still hope there will eventually be a world-wide standard, instead of dozens, but at least the EU mostly uses just one)
  • USB
  • Train track widths
  • DIN A4, A5 paper formats
  • JDBC
  • JMS

All of these standards simplify business for everyone by destroying the business of those who try to sell deviating, proprietary interfaces. For example, DIN A4 means 297mm x 210mm. Vendors of printers, photocopying machines, document processing software, paper, envelopes, binders, briefcases, etc. etc. can all support “the standard” and consumers don’t have to purchase a briefcase for JAXenter publications and a different briefcase for other documents.

A bad standard is a “standard” that hinders innovation by adding complexity in a very opinionated environment.

JDBC is an exceptionally good standard in software, as it removes the need for knowing about vendor-specific APIs and network protocols in order to access mostly RDBMS (although it works also with other data stores).

There are some good Java EE standards, like JMS, Servlets, JavaMail and others, mostly those that define (again) protocol abstractions, or things that are too boring to be implemented a second time in a different way (JAXB, JavaMail).

A bad standard is a “standard” that hinders innovation by adding complexity in a very opinionated environment, where differing opinions are good for the market, as each opinion can vary greatly in how it adds value to a consumer. There are a lot of business standards like the ISO 9001 for quality management or the ISO 29119 software testing standards, which are mostly certifications that companies like to show off to impress customers. They don’t really mean anything concrete as it is much too complex to derive from a simple yes/no flag what this really means in the context of a concrete corporation.

Java EE “shines” here with bad “standards” like EJB, MVC, JPA, JSF, CDI, Bean Validation, Batch, and much more. All of these things do not belong in a standard because they are:

  • Complex
  • Often a bad default choice
  • Often not the only choice, specifically not the de-facto choice (e.g. bean validation, batch)
  • Very opinionated in terms of architecture and design, which greatly restricts the solution space for consumers

Take JSF, for instance. It’s a server-side UI component API specification. How many component APIs did we already have? AWT, Swing, JavaFX, Gwt, Vaadin, Wicket, JSF, and many others, lesser known ones. In this case, JSF is “just another” component API (specification). Of course, it’s one of the most popular ones today, but that’s only the case because it profits from the Java EE “brand”.

JPA is a different story. It solves dozens of problems, which is a very bad thing for a “standard” API. It solves:

  • Mapping (that’s the best part)
  • Querying (in several different, conflicting ways: mapping, utility finder methods, JPQL, criteria API, fetch graphs, native queries, query annotations, etc. etc., none of them are satisfactory, given that SQL is incredibly more powerful)
  • Native SQL (in my opinion, the stored procedure support shows the desperation in this API to keep up with real world needs by shoe horning a feature into an API that was not designed for the mere existence of stored procedures)
  • Transactions (Why? There’s already JTA…)
  • Locking
  • Caching

It’s a heterogeneous monster that should be split in 10 different APIs. Don’t get me wrong. It’s fine for an *implementation* like Hibernate to offer all these features out of the box. But the specification shouldn’t do that. It’s simply not a good standard.

To answer your question: As I mentioned already in my previous answers, the industry likes having guarantees that certain things work together. It’s good to know that JDBC works and that jOOQ or Hibernate work on top of JDBC and that none of these APIs will break in the future. JDBC is a standard. jOOQ and Hibernate aren’t. They’re complex tools that profit from the standard. They drive innovation. They add things, deprecate things, remove things. They should not be standards. Otherwise, their complex innovation will stop.

I’m hoping that the MicroProfile initiative will take a fresh look at “standardization” in Java and prevent the “standard feature creep” that has happened in J2EE and later on in Java EE from happening. Mark Little’s comment on the topic looks precisely like it.

 

Java Rock Star Adam Bien

JAXenter: Considering the current state of Java EE, did we need an initiative like MicroProfile? Should Oracle take part in this initiative?

Adam Bien: Sure! Oracle is highly welcome.

JAXenter: Do you think MicroProfile will have any impact on Java EE Guardians? 

Adam Bien: Java EE Guardians is just another group of passionate Java EE fan girls and fan boys. I’m sure they appreciate it. At least they retweeted everything what was microprofile.io-related.

I will ask the Java EE Guardians about their opinion next time I get the chance.

JAXenter: Mike Croft said that the JCP involves more than just Oracle while Lukas Eder opined that the JCP is Oracle. What is your opinion?

Adam Bien: I asked the question myself. I asked Heather VanCura What is the relation between JCP and Oracle? The answer can be found here.

Oracle has a permanent seat on the JCP Executive Committee (EC), and together with the other EC members, the EC votes on the work of the Expert Groups and evolves the JCP itself. The EC is led by a non-voting Chair from the PMO; the PMO is the group within Oracle that is responsible for administering the JCP and chairing the EC. The EC does not micro-manage the day-to-day workings of Expert Groups – the EC has the opportunity to review the work of each Expert Group at well-defined points as their specifications proceed through the JCP program. The primary function of the EC is to ensure that specifications do not overlap or conflict with one another and that the specifications meet the needs of the industry segment for which they are being written.

Heather VanCura

On the spec-level it is even clearer. Some specs JSR-365, CDI 2.0, Dependency Injection for Java, JSR 330 were / are led by other companies entirely without Oracle.

More to come. 

If you’d like to take part in our debate, drop us an email at editor@jaxenter.com.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of