As laid out in the canonical MicroProfile slide deck, the time gap between each release of Java EE has grown larger. Some of this can be attributed to the maturity of the platform for traditional “monolithic” applications, some due to vendor re-tooling their implementations to be more modular, and some due to the size of the Java EE platform itself and a vendor’s ability to QA (quality assure) products. The application platform world, however, is moving faster and faster. Agile, DevOps, and the Cloud/Containerization have completely changed the way developers deliver software. Organizations have gone from sprints as a way to deliver features into a big-bang product release, to delivering features into more frequent incremental “dot” product releases, to a potentially an intra-day release cycle where a release is defined by a git commit. There is an impedance mismatch between the way Java EE defines and delivers a release with the way developers want to consume it.
The Java Community Process is a standards organization. Its primary concern is to build a stable foundation through industry collaboration and consensus. Innovation is heavily enabled by a stable, reliable foundation so in that sense the JCP is important to the Java industry. Without it, we wouldn’t have WildFly Swarm, WebSphere Liberty, Payara Micro, TomEE, DropWizard, Hammock, Spring Framework/Boot, and the list goes on. However, Java developers want to move forward faster. They feel an impedance mismatch with Java EE. They want to consume a stable platform in the same manner they deliver their products – incrementally. Incremental change with Java EE means delivering features sooner and with less risk. For example, Java EE 7 attempted to go down the big-bang cloud route circa 2012 and failed because the effort was premature. Java EE 7 was re-planned to what we have currently. Java EE 8 tried a big-bang release and is now being re-planned. We should have learned a lesson. Twice. I had a hand in some of that (up until Aug 2015), so feel some sense of personal responsibility for it. Let’s say that I have learned my lesson
Enter MicroProfile circa June 2016 announced at DevNation with Red Hat, IBM, Tomitribe, Payara, and the LJUG all on stage. With work on Java EE 8 having essentially stopped at the time except for a few in the community, some Java EE vendors and community members got together with the desire to define a path to Microservices for Java EE developers. We understood that we were doing really innovative work individually, but felt that there was value in collaboration where there were common problems to solve. MicroProfile got off to a fast start by delivering its first release just prior JavaOne. JavaOne also revealed the Java EE roadmap – Java EE 8 in 2017 and Java EE 9 in 2018. The point made loud and clear by developers at JavaOne was to not have competing efforts. The Java EE community doesn’t want it, nor does the MicroProfile community.
With MicroProfile 1.0 released and Java EE 8 having re-started, here is a proposed strategy that David Blevins articulated quite nicely – “the MicroProfile can innovate and feed the JCP with JSRs”. Think of it as an upstream open source Java Microservices project for the JCP. There is general consensus that Java EE 8 should proceed, albeit in a slightly different form that was defined a couple of years ago. Yes, its a big-bang release. However, most of the work is done and we need to re-establish momentum. Java EE 8 is a good first step. I personally prefer that the proposed Health Check and Configuration JSRs be done first through the MicroProfile effort and will advocate for doing so. I suspect that my position will lose, but you win some and you lose some. Now, what to do about Java EE 9?
I’ll be rather blunt – Java EE 9 by 2018 is not going to happen. It’s too big a scope in too little time without enough experimentation to address some pretty fundamental changes to the programming model. Even if we work 24x7x365 to define it, implementations won’t happen until 2020 (at best) because vendors first have to finish Java EE 8 implementations. Of course, skipping Java EE 8 and going straight to Java EE 9 is a real option for vendors. Regardless, the microservices world will have passed by Java EE 9 well before that. Let’s avoid a third misfire and directly address the impedance mismatch mentioned earlier. We need to get real bits in developers hands sooner. We can do that by leveraging the open source model. Instead of an expert group defining an API up front, lets crowdsource an implementation. If we fail, we’ll fail fast. If we succeed, then we’ll propose a JSR and encourage multiple implementations. Insert your favorite “feature” here (Circuit breaker, NoSQL, service discovery, etc). Let’s build out the feature over a collection of sprints. Get developers using it in production along the way (canary testing recommended 😉 ). Get real-world feedback. Iterate that a bit. Propose a JSR (with a ready-made Reference Implementation (RI)) to tidy things up, and then vendors can add it to their runtimes as soon as they are able to. Rinse and repeat. We can decide if we want to do this one feature at a time or run a number of them in parallel. We deliver a stream of standards in developers hands more quickly backed by real world use, while enabling multiple implementations.
The above release strategy is only an outline. It starts with MicroProfile by collaborating on an open source implementation and ends in a standard API and ready-made RI, and maybe even TCK. Please, let’s move away from big-bang platform releases and develop a platform the way the market wants to consume it – incrementally.