Why MicroProfile after javax?

It wasn't my intention to write more on this topic as I want the discussions to be had in the community forums. However, since writing my first article I've seen some confusion on the Twitter-verse and perhaps some FUD so I figured I'd write a couple more articles here, of which this is the first. Hopefully they help fuel the debate.

Hopefully you've read at least my JBoss blog about the javax namespace problems and my personal blog outlining my preference for how we move forward from this point. Since posting them both I've read a number of people ask “Why MicroProfile?” Or “Why can’t we just innovate in Jakarta EE?” I want to try to answer those questions but recall this is still my personal opinion not that of my employer.

I think what some people are missing is that I'm not arguing against innovating with Jakarta EE components. I'm discussing where to do that innovation and why. And this isn't an easy choice for our community to make. No matter what we do there are risks and I want to make sure everyone understands that there are no right or wrong answers here. As long as we make an informed decision as a community I'm sure we can move forward constructively. I'm sure some people won't agree with the decision(s) but as long as we have a good debate I hope everyone will get behind the new direction and put their feelings aside.

OK so back to the original questions about why I'm suggesting we focus our innovation efforts around MicroProfile. Well think of it this way: if there was no MicroProfile and we wanted to evolve Jakarta EE today then where would we look for influence and inspiration? If “The Cloud” isn’t in your top 2 then you should probably go sit this one out. Now that leaves us with the obvious question of where do we do this work? My preference, as I've already mentioned, is MicroProfile and make Jakarta EE the stable solution for existing Java EE end users. I'm not saying this because Red Hat has a MicroProfile product, which we clearly do, but we also have an industry leading Java EE product, just in case anyone missed that! This is about developers and end users. And what they want today. In big shops and small. For their new applications. Cloud is their biggest concern and how to develop for it.

Naturally we could evolve Jakarta EE towards cloud-native. That was the original remit for Jakarta EE after all. But I believe the namespace issue changes things because prior to this we were probably going to be able to get away without having to touch much of Jakarta EE, or perhaps not for some time anyway. In the meantime we'd be able to focus on those aspects of it which are needed in that particular problem space, bringing in new things which aren't there too (e.g., Istio integration). But clearly that isn't going to be possible now and we're going to have to invest some time and effort in all of the specifications.

Now you can argue how much effort that will be but even if the code changes can be masked to end users, they still need to be made within the TCKs, docs etc. And of course there is the knock-on effect on training courses for Java EE 8, books etc. It will all take some time. It will likely divert the attention of many people who could well be used to help innovate. And in that time what else happens in other areas of our industry which we may miss? Is the rest of the world going to stand still? We risk stagnation and developers migrating elsewhere, which is precisely why Red Hat, IBM, TomiTribe, Payara and others created MicroProfile in the first place over three years ago. Let’s face it, Java EE innovation stagnated for quite a while. MicroProfile represents the most intense effort of innovation any of us have seen based on a select number of aspects of Java EE for many years. As a Java EE community we should all be proud of that and not see it as a threat!

A threat, I hear you ask? Yes, apparently some people are now suggesting MicroProfile is a threat to the future of Jakarta EE, despite the fact the latter exists today due to a number of factors and MicroProfile is up there near the top! I'm not going to even stoop so low as to respond except to remind everyone that very few companies have as much invested in Java EE than Red Hat so anything I discuss here is not done without careful consideration. If that doesn't help then nothing willl.

Anyway, back to the question at hand. The logical alternative to starting to evolve Jakarra EE towards cloud native is to jump to the end game, or somewhere on that road. And I believe that MicroProfile does precisely that for enterprise Java. Recent surveys from the Eclipse Foundation and others back up this assertion. The MicroProfile community has done a great job so far and should be congratulated.

If you've looked at MicroProfile recently then you'll know it uses a few Java EE specifications, such as CDI and JAX-RS. It doesn't seem to need more than those just yet. However, if more Jakarta EE pieces need to be evolved then pull them in. Push them back to Jakarta EE if needed but don’t make that a requirement. Use the momentum that we've all built up around MicroProfile to keep driving forward. Maybe some Jakarta EE specifications need replacing completely for the cloud, e.g., transactions or messaging. Reactive is not something which can be easily applied to all of the current Jakarta EE specifications so why not just start with a much more focussed (limited specifications) approach, as MicroProfile is doing? Can you imagine the can of worms we might open if we wanted to make Spec A reactive only to find that impacts B, C and D, with other cascading impacts from them?

So if the community still believes that pieces of Java EE have a role to play in cloud-native microservices, I suggest MicroProfile is already a far better starting point than where Jakarta EE is today. Now as I stated in an earlier blog post you might not agree with me and that's fine. Perhaps the reader believes there’s something else other than cloud-native microservices that people want to innovate around using Jakarta EE? Great, let's hear it and open a discussion. How many people are willing to contribute their time and maybe even money to it? If Jakarta EE is to not only survive this javax namespace issue but thrive then it needs people to stand up and be counted against GitHub commits.