JavaEE 8 has been delayed, yet again.

There’s something very odd going on at JavaEE HQ.

Article from The Register here, and InfoQ here

Oracle are selling this as a good thing as it gives them a chance to “cope with the prevailing winds in development and deployment”, which I read as “we’re going to get microservicey and we’re going to cram in some Dockerish type stuff as well”.

Why is JavaEE even needed today? Some organisations like the stability and security that a standards process offers. But all of the components of JavaEE, such as CDI, EJB, JMS, JAX-RS etc, etc, are all standards in their own right. We cover these in our excellent Wildfly Series of training courses.¹

Is an overarching “umbrella” standard, keeping an almost uncountable number of unrelated APIs in lock-step really relevant in today’s agile development world?

Rather than waiting until 2017 (get real, it will be 2018 at earliest), Java(SE) is a leading cloud and microservices solution TODAY, using a multitude of battle-tested industrial strength libraries. Some of those fall under the JavaEE umbrella (JAX-RS, JMS or even EJB), whilst some come from commercial companies donating their software to the community (such as Netflix OSS ², which we’ll be covering in the upcoming Microservices course).

While they’re stuffing in new toys, they’re also cutting. With all the precision of a newly qualified surgeon who’s just celebrated by downing 8 shots of absinthe. The proposed standard (JSR 371) for an MVC framework is being dropped – because “microservices are often headless, so an MVC framework is not needed” (they claim). But as far as I know, JSF will remain. I smell a rat here, JavaEE has never been afraid of shoving in niche APIs. And MVC wouldn’t be niche – although it would be (at least) 10 years too late, a specified MVC would have been a valuable counterpoint to Spring-MVC.

I admit I’m annoyed by this. I like JSR371, it’s not glamorous but it would have done the job. It cleverly uses the same patterns as JAX-RS so it’s quick to learn. It has a reference implementation here so technically you can use it today. But if you’re on a JavaEE project that insists on standards, you have to wait until it’s absorbed into JavaEE, which at the time of writing is quarter-past-never. Because, by their own admission, it’s not trendy enough.

Are JavaEE really saying that nobody’s building web applications any more? JavaEE web developers are currently stuck between bringing in a non-standard web API (choose from hundreds) – hence nullifying the whole point of JavaEE, OR they are stuck with using JSF, a terrible tool for building action-driven web applications. (It’s good for component based non-navigational web apps, and it’s much better than it used to be. But still, not the tool I’d chose unless forced)³.

To add to the craziness, there’s also talk of JMS being frozen at version 2.0, because “it’s not relevant to the cloud”. Which makes a fool of me, because I claim that messaging using a guaranteed delivered mechanism like
JMS is a great way of calling Microservices. Ok, well I’ll carry on doing “irrelevant” stuff, deploying working software while JavaEE carries on ruminating behind their closed doors.

This is, in my opinion, extremely bad PR for Java, making “us” look like a committee led dinosaur. The true picture of Java development is extremely exciting, and non JavaEE libraries continue to lead the way in pushing the industry forward. Java will never be cool again (oh for the heady days of 1996), but it (and the JVM) delivers big and I hope this will continue. With or without Oracle’s “help”.

^{1. [There’s nothing wrong with application servers, we’re using Wildfly heavily right now. We find you can be very agile and it’s a great fit for Microservice development (as is Spring Boot)]↩}

^{2. [I’ve seen proposals for client side circuit breaking, externalized configuration stores and health checking for JavaEE 9, which suggests that are going to absorb the NetFlix OSS stack into the standards – again, by then, the state of the art will probably have moved on by a leap or bound or both]↩}

^{3. [I almost forgot JavaScript front ends, which of course is a very common choice. They could have used this as their excuse not to bother, but then they’d have to admit that JavaScript exists and can do some things better than Java]↩}