Back in early 2014, Oracle released the results of the Java EE community survey, which was created to gather feedback about what developers want to see in Java EE 8. One of the questions in the survey was whether people would like to see an MVC web framework alongside with JSF in Java EE 8. The result was pretty clear. More than 60% of the participants voted "Yes". As a result, JSR 371 (MVC 1.0) was started to work on the new action-based web framework for Java EE.
Fast forward to 2016. JSR 371 has been doing well. The EG released the second early draft review and got a lot of positive feedback. The JSR was moving forward even after Oracle suddenly stopped all work on the Java EE JSRs.
Recently, Oracle announced the revised plan for Java EE 8 during JavaOne 2016. Surprisingly, Oracle now questions whether an action-based MVC web framework is still relevant in the cloud age and therefore proposes to drop MVC 1.0. At the same time, Oracle started a new survey to get feedback about the revised plan for Java EE 8. This survey contains the following statement:
When we first proposed Java EE 8, we got feedback that an action-based web UI MVC framework standard would be a good addition to Java EE. [...] We're now questioning whether it is still important to complete the MVC API (JSR 371).
I don't understand how Oracle comes to the conclusion that MVC is not relevant anymore. People wanted it in 2014, and the EG is getting great feedback for the work done so far. So what changed in the last two years?
I was wondering what people really think about JSR-371 (MVC 1.0) in 2016. So I had a look at the survey results of the DZone Java EE survey which was created with the help of the Java EE guardians. I checked all the comments referring to MVC, especially from people which considered MVC as "not important." Then, I created a list of representative comments and wrote down my thoughts about them:
"Modern Web Applications Use Stateless REST Services Anyway"
However, if you have been around long enough in the IT industry, you have hopefully learned that there is no silver bullet. Never. Developers created various web application frameworks for decades. And guess what, nobody ever created a framework which solves all your problems. That's why there are so many of them. There is no "right" and "wrong" approach for web frameworks. There are different categories of frameworks that address different problem domains. You have to choose the right tool for your specific requirements. If your application is not highly interactive and if you have to deal with SEO requirements, a server-rendered web framework may be your best choice. And in this case, MVC 1.0 will be a great option.
Searching for silver bullets seems to be a common phenomenon in our industry. Some people seem to think, for example, that NoSQL databases like MongoDB, Redis, Cassandra, and others are the silver bullet for storing data. No, they aren't. There are many use cases for which MongoDB is a great fit, but depending on your specific requirements, a classic relational database may still work better. The answer is simply: It depends!
So I think it totally makes sense to provide an alternative web framework in Java EE, which implements a completely different concept than JSF. Neither of the two frameworks is right or wrong. They are different. So you can use Angular + JAX-RS, classic JSF, or the new MVC framework depending on your needs. Having a choice is a good thing.
"The Same Can Be Achieved With JAX-RS"
That's true. JAX-RS is a great foundation for creating web applications. That's why MVC is based on JAX-RS. Actually, MVC is just a very thin layer on top of JAX-RS, which provides everything you need to build a server-rendered web application with JAX-RS. So MVC doesn't reinvent the wheel, but builds on top of what the Java EE platform already provides. You should have a look at the latest API. I'm sure you will be surprised at how easy it is to create a web application with MVC 1.0, compared to doing it manually with plain JAX-RS.
"If a New Framework Is Added, Completely Remove JSF Beforehand, or it Will Be too Complicated for a New User to Choose"
Well, dropping JSF would be a REALLY bad idea. Backward compatibility is a key feature of the Java EE platform. If you invested in JSF by building applications using it, your investment will be safe. Future versions of the platform will keep supporting JSF for the foreseeable future. And that's great, unless your boss allows you to migrate your application to a new shiny web framework every month. But I guess that's not the case. ;-)
If MVC 1.0 gets included in Java EE 8, you will have the choice between two web frameworks. And that's great. Ed Burns wrote a great blog post about this topic. I highly recommend you read his post. The key message is that component-oriented and action-based web frameworks are completely different concepts, and both have their right to exist. Why? Remember, there is no silver bullet. You should use the framework that best fits your needs. The same is true for other technologies. If you want to process XML, you can either use low-level APIs like DOM/SAX/StAX, or you could use an object mapper like JAXB. Which one to choose depends on your specific situation.
"I Think it Missed the Train and Now Comes too Late"
Well, in my view, a JSR like MVC 1.0 should always try to standardize things that are proven to work well in practice. Therefore, creating a JSR to standarize well-established concepts can never be too late.
JPA is a very good example of this. Prior to EJB 3.0, persistence in Java EE was a very heavyweight approach. Most developers weren't happy with it. That's why people preferred third-party solutions like Hibernate. So Hibernate became a de facto standard for ORM in Java. The JPA specification then created a standard that was heavily influenced by Hibernate. Which is a good thing. Remember that standardization should focus on technology that is battle-tested and works well in practice. So did JPA, and that's why Hibernate and JPA are very similar.
The same should be done for MVC. Of course, there are many MVC frameworks out there. And that's good because today we know which concepts work best. The most popular MVC framework in the Java space is Spring MVC. That's why MVC 1.0 is heavily influenced by Spring MVC. Some people criticize that MVC 1.0 copies Spring MVC too much. But these people don't understand that using concepts from well-established frameworks for standardization is a good thing. Standards should look at the best technologies out there.
"Happy With Spring MVC :-)"
Hey, you're using Spring MVC? That's great! Spring MVC is awesome! If you are happy with it, there is no good reason to migrate your apps to MVC 1.0. However, if you are creating a new application on the Java EE platform, using MVC 1.0, which ships with your container, may be an interesting option. Especially if you are using Java EE technologies like CDI, JAX-RS, Bean Validation, and friends. In this case, including Spring in your project just to get the web framework wouldn't make any sense. But if you are typically using the Spring framework and other components of the Spring ecosystem, you should definitely go with Spring MVC.
"Too late. Enhance JAX-RS"
Back then, before JSR 371 (MVC 1.0) was started, there were quite a few discussions about whether web framework support should be added to JAX-RS directly, or if a separate specification would make more sense. At that time, the JAX-RS EG decided that adding web framework related concepts to the core JAX-RS API would not be a good idea. So a separate JSR was created. However, as I mentioned before, MVC 1.0 is based on JAX-RS. So I could argue that MVC 1.0 is actually an enhancement of the JAX-RS spec. It's just a separate specification bundled in a separate JAR, which is using a different package name.
Thanks for reading so far. I hope you liked my thoughts about MVC 1.0 and Oracle's decision to drop it from Java EE 8. If you agree with me that MVC is still relevant and should be included in Java EE 8, please fill out the new Oracle Java EE survey and help to convince Oracle to keep investing in MVC 1.0.