On November 28th, Oracle announced that they were withdrawing the JSRs for Management 2.0 (JSR 373), and JMS 2.1 (JSR 368), based on the feedback from the community. Furthermore, they are investigating a possible transfer of MVC to another community member or organisation in order to complete JSR 371 as a stand-alone component.
This is in line with the pledge at JavaOne to listen to community feedback, and pursue an aggressive roadmap for Java EE that supports “New AppDev Style for cloud and microservices”.
In October, Java Champion Ivar Grimstad looked at the possible ways forward for MVC 1.0. We caught up with him following the most recent announcement to get his take on it.
Do you think the recent survey and call for community involvement from Oracle at JavaOne has helped to prioritize Java EE JSRs for the better?
I certainly hope so! What I find a bit worrying is that there is a lot of mentioning of the survey results from various sources within Oracle, but nothing has been published yet. It has been more than a month since the survey ended and there are clearly some results available that these decisions are based on.
What is your opinion on Oracle’s announcement to drop MVC 1.0 (JSR 371)?
Ideally, I would have preferred that MVC would be to be a part of Java EE 8. But given what was announced at JavaOne and the indicated survey results, this was likely not going to happen. So transferring it to the community for completion as a separate spec is the best thing given the circumstances.
What are the implications of MVC being a separate spec?
This is just speculation from my side, but here are a couple of thoughts. First of all, since MVC 1.0 is not a part of Java EE, it will not automatically be supported by the implementations. That will probably mean that Ozark, the reference implementation, will have to be portable across application servers. This will also have impact on the licensing.
Being a separate spec also opens up for shorter release cycles independent of Java EE versions.
What are the options available for developers who were counting on JSR 368?
Regarding JSR 368, which is JMS 2.1, it should be noted hat JMS 2.0 is still to be a part of Java EE 8, so the consequences for developers are not that severe. JMS 2.0 is s significant improvement from previous versions and JSR 368 was all about making it even easier and more flexible. But 2.0 is still an excellent technology. There are also discussions going on in various forums about messaging in microservice oriented architectures.