Why?
Why not JSF? Why another MVC framework?
The Java community was polled about what new features they wanted to see in Java EE
8. While 61% of respondents answered "Yes"
to the question as to whether we should provide MVC support alongside JSF, only
26% felt that they could identify an existing technology here. Most requesters want a formal Java MVC API
that can compare to Spring MVC. The third phase of the poll looked at all the technologies that received 60% or more votes. In that poll there were 13 areas and the MVC JSR ranked 5th.
This JSR is in no way
meant to take anything away from JSF. (In fact in the new JSF proposal
they are planning on supporting the MVC JSR.) It is instead intended to provide
an alternative implementation to the MVC pattern. JSF is a component
based MVC framework, while this JSR is a request (action) based MVC framework. The main difference is that JSF allows very little fine-grained control
over the generated HTML/CSS/JS, whereas this JSR will provide that detailed
control. Both framework styles have their place and value but one is not the
other.
The MVC JSR proposal was just announced on the JAX-RS mailing list and will be led by Santiago Pericas-Geertsen and Manfred Riem from Oracle.
I
have been thinking about MVC for a while now. I had actually considered submitting my own proposal until I found out
that Oracle already had one in the works. After comparing notes with Santiago and Manfred, we realized we could
work together on it. One of the biggest reasons that I wanted to work on the MVC spec is that I have spent years working with Spring and Spring MVC. In fact, my current role at Red Hat is the Spring lead for JBoss. I make sure that Spring works on JBoss/WildFly. Additionally I have worked with server-side frameworks like Struts and VRaptor and client-side frameworks like Backbone.js and Angular.js. That is why it felt like a perfect fit for me.
What is MVC, if you are still wondering? For those of you that are unfamiliar with this design pattern, here is a bit of an overview and some insight into what I hope we build.
The Model View
Controller (MVC) design consists of three kinds of objects. The Model is the
application or data object, the View is its screen presentation, and the
Controller defines the way the user interface reacts to user input. Before
the use of the MVC pattern, user interface designs tended to lump these objects
together. For example, JSPs sometimes merge database code, page design code,
and control flow code. In practice, we find that unless these concerns are
separated, larger applications become difficult to maintain. MVC decouples
these concerns to increase flexibility and reuse.
Frequently application
developers implement the MVC pattern in applications themselves which is
expensive and error prone. This specification aims to help developers create
web applications that utilize the MVC architecture without reinventing the
wheel. This shortens the development time of applications using the MVC
pattern.
The decoupling of the
View and the Model is done by establishing a notify protocol. A View must
ensure that its appearance reflects the state of the Model. Whenever the
Model’s data changes, the Model notifies Views that depend on it. In response,
each View gets an opportunity to update itself. This approach lets multiple
Views be attached to a Model to provide different presentations. New Views for
a Model can be created without rewriting it.
Depending on context,
users want to see the same basic Model information in different ways.
Separating out the View from the Model and the Controller allows the
development of multiple Views from the same Model. Most noticeably this
could be providing the same Model to a rich client, a Web browser, a remote
API, and a command-line interface. Even within a single Web interface you might
have different customer pages at different points in an application.
After working with both
server-side and client-side MVC frameworks; I have a simple goal. Make MVC easy to adopt and powerful enough to
use. Many frameworks are cumbersome to
learn, while others are too light weight to be of any real value. I am aiming at striking a balance between those two.
Additionally, I will be
able to make sure the MVC API is implemented on Red Hat JBoss (WildFly) in a timely fashion.
Hi
ReplyDeleteI think the new MVC API must have real time capabilities (websockets etc.) like meteorjs, play framework and not to force you to use JSF as front-end technology.
Thanks Odemis for the feedback. I completely agree. I updated the post. The specifics of how we do that and what gets done will be hashed out in the EG.
DeleteThank you very much for your effort for a flexible MVC that Java developers have been waiting for a long time. This project will be a milestone in Java EE history and very helpful for developers.
ReplyDeleteHi
ReplyDeleteI am confused as to why we in the Java EE community need to standardise around a Model View Controller API. I have been developing web applications since 2001, with Struts. There are lots and lots of web request oriented frameworks out there. I think it is bit too late to standard them now. As a business owner, I would just pick the best web framework out there, suitable for my needs, and then write production code against it. I feel it is rare case, that I, then, suddenly need to switch from Struts 2 to say Wicket or JavaServer Faces on a whim.
I am missing a use-case here or there?
I think the real battle for Java EE 8 is the out-dated HTTP Servlet AP 3.1, which is a wrapper around HTTP, which inflexible against the current RESTful endpoint design trend and this is weakness that other framework like Play have exploited. The Play developers focused on mapping URI to action controller methods (in Java and then in Scala) as a USP unique selling point. The other weak point of Java EE 7 is the several ways that developer, we have to encode and decode objects from JPA, JAX-RS, JSF and CDI have their different Java Interfaces and strategies. This is why I believe a MVC is moving attention away from pressing design requirements that in my opinion should have higher priority.
I do know that there will be a JSR for Servlet 4 and I can only hope that they resolve these issues. https://java.net/projects/servlet-spec/lists/users/archive/2014-07/message/0
DeleteAs I stated above I have used several MVC frameworks (including Struts). I only wish that Java MVC had come out sooner. I think you are asking 2 questions at the same time: Why should Java create this standard/API? Why should you use it or care about it?
To answer the first, because the community requested it. I think that if we can leverage the updates to Servelts, JAX-RS, CDI, and maybe even the new JSON spec then we can create something that makes using the MVC pattern easier. At least that is my goal.
To the second question; It is both a personal and corporate choice. I remember having the same discussion on a project when we were trying to decide between Spring and CDI. Do you pick the popular one or the standard. Personally, I like having options. It is up to you which one you use. I would like to think that if you are starting something new you would try the standard and it would be easy enough to use that you would like it. (But I am just hopeful about it right now, we will see)
Hi Joshua,
ReplyDeleteHas RedHat considered adding an MVC framework to WildFly in the meantime? Two years is way too long wait for a spec, much less a full release, and the creation of the spec would benefit greatly from real world usage and iterative development. Microsoft released their MVC 1.0 product 5 years ago and they were already 4 or 5 years late to the party back then. RedHat needs to move with more agility than the JSR process will allow
Wildfly has all the components of a modern web app server with the glaring exception of an action based MVC framework. Undertow, Weld, Bean Validation, Hibernate, Infinispan, RestEasy and HornetQ are all well designed, battle tested components. Bringing them together using a highly productive action based MVC framework will make it much easier for existing Java developers, as well as new developers coming from other languages, to take advantage of them in a way that is easy, fun and powerful!
Making it available out of the box on Wildfly and with RedHat's support behind it will go a long way to driving adoption. The only thing a new user would need to do to test it out is a spin up a Wildfly instance on OpenShift.
You mentioned VRaptor, in your post. I am just looking it for the first time today, but so far it looks pretty good. The fact that it already uses CDI, JPA and Bean Validation make it seem like it could be a great starting point..
Action based MVC has been strongly demanded by developers since Java EE 7. Java EE 8 poll result shows that the MVC is in more demand than cloud which is one of the main theme of Java EE 8. But it will take more than 2 years from now to get the MVC available for use.
DeleteBy considering all these things, why Redhat should not consider providing a production quality implementation of the MVC early draft version as early as next year? This will be greatly appreciated by developers and help to get valuable feedback to fine tune the final version of the MVC.
While I understand your desire to start using it right now, it is important to remember that the JSR was just filed and it takes time for the standard to evolve. We'll be watching the RI builds closely and integrate them in our upstream.
Deleteprojects as they are made available.
On the one hand, I can't believe that it's taken this many years for Oracle to get around to implementing a proper MVC framework. This should have happened 10 years ago! Sad thing is that it is going to take even more years before this is done! And that is to get us where Spring MVC/ASP.Net MVC were years ago. It's almost too little, too late.
ReplyDeleteOn the other hand, better late than never! It would be cool to have a built-in MVC framework. This is something I've wanted for a long time.
I have never liked JSF. Just making a 'hello world' page with two text fields and a button results in a HTML that is completely broken/invalid and a huge amount of magic JavaScript. I hate it. Please make sure that the EE MVC does not even remotely resemble JSF.
Also, PLEASE don't re-invent the wheel, or be different than established MVC frameworks just to be different. If I were you I would have a -very- hard look at Spring MVC and ASP.NET MVC 6 as guidelines for what the Java EE MVC could be. Both are mature and widely used frameworks, and I hope the EE version uses the same basic concepts/patterns (i.e. make a class with @Controller on it, put other annotations on the action methods, etc.) I have never used VRaptor before....it looks really cool also....I like the simplicity! I hope the EE MVC is simple like that.
The point being, most people who are interested in MVC are probably -already- using MVC today. The EE MVC implementation should be easy for them to migrate to should they wish.
(SIDE RANT: Can we get proper JSON support in the Java 9...I mean integrated into the language? Also, can we get rid of the ridiculous getters/setters that plague Java code today? Finally, JSP is fine, but can we get a new/modern view engine (i.e. copy ASP.Net Razor like Play framework did)?)
Anyway, I wish you the best of luck!
I hear what you are saying. As I have previously stated, my goal for this is to make it as easy to adopt and use as possible while providing all the functionality needed.
DeleteAlso, my vote is for defining a controller with @Controller too. :)
All of this will be worked out in the EG, so please follow along with what happens there. Either join or at least review and provide feedback. I will continue to try to share what is going on as it happens. Follow me on twitter for real time updates. @javajoshw
Yes, a controller should be @Controller, simple and straightforward, no confusion at all! I also vote for that. :-)
DeleteOne last (but important!) thing....is this new EE MVC api going to be able to support Async/Non-blocking requests like ASP.Net MVC?
ReplyDeletePeople are ditching Java EE in many cases because competitors are fully async (i.e. node.js, ASP.NET MVC, etc.). Being non-blocking results in HUGE scalability gains.
Synchronous server-side code in 2014 has a really bad name. Listen to the walmarts, paypals, new york times, dow jones, ebays, linked ins etc. of the world who are ditching Java in favor of async/non-blocking node.js.
Since the Java EE MVC is a brand new API, this is the perfect opportunity to modernize.
Please include non-blocking/async support in Java EE MVC!
I would like it to try to be Async. With the new Java EE 7 Concurrency API we might just be able to do it. I think Servlet 3.1 worked something out for Async. Once again this will be up to the EG but thanks for bringing it up.
DeleteKeep the ideas coming.
Sound good. My only concern though is would a dependency on Java EE 7 features prevent it from running on a vanilla server like tomcat? I sure hope not.
ReplyDeleteI am not sure what will happen yet but that is something I want to keep in mind too.
DeleteThis comment has been removed by the author.
ReplyDeleteSun/Oracle JSR has a habit of creating standards that are inferior to defacto standards that are already out there. It then takes numerous major releases before becoming usable, if ever. This could add considerable more time beyond the 2 years ie. way too late.
ReplyDeleteExamples:
standard logging versus log4j slf4j, log4j2 and logback
CDI vs Spring
...
JSF1 vs JSF2 [ha ha] ; unusable vs tolerably usable
A lot of times major achitectural defects goes unrecognized and thus untreated.
In JEE, you will likely be tightly integrating with these defective technologies which could detract from what you have accomplished. Long story short you have your work cut out for you.
...
JSF 2.2 pass through elements failed to address being able to create mockup in just a browser ie. easy for designers.
You will have a similar problem of being easy for testers. Programatic calling controllers outside of a web context. This is useful for programmers too as sometimes HTML needs capturing to be sent to email or translated into pdf. JSF has also failed in the regard but failing to provide a outside/inside of the black box API.
Please learn from the mistakes/defects of your competitors before stripping out 90% of their functionality and calling it standard.
Personally, I would like to OSGI modules with BluePrint ie. Spring like xml configuration files, a MVC like SpingMVC and RSF for the component MVC. Too bad Spring no longer does OSGI, Oracle seems to have Sun's interest in giving the Java community reloadable modules and services, RSF died before the Java community relized it exist and its philosohy of strict MVC is the best way because it keeps us programming in Java instead of some mongrel language.
You should also see about using your influence to push the language JSR to give us databinding ~ie. functional/lazy loading ~ie. compile time reflection. Let me explain. It would be nice if we could write (return type).memberName.memberName[indexerNameOrOrdinal].memberName and have it evaluate to the following 4/6 method interface.
// (return type).memberName.memberName[indexerNameOrOrdinal].memberName
interface CompileTimeProperty
{
Class returnType;
String lastMemberName;
lastMemberReturnType compiletime_getter(instance of return type);// returns null if any member is null
void compiletime_setter(instance of return type, lastMemberReturnType );
// works with module than application overrideable converter framework for forgiving conversions
// true = "true", "on", "yes", "t", "X", "1", "-1"
// false = "false", "off", "no", "f", "", "0"
Object runtime_getter(Object);// returns null if any member is null
void runtime_setter(Object, Object);
}
I figure something like this could JSF or other template engine with type safe EL expression. This is similar to the new functional programming but isn't a single method. This is akin to complie time reflection for being able to change a member of a object. This is meant for simple compile time data binding
This comment has been removed by the author.
ReplyDeleteJSF was created in early 2000s to facilitate a visual IDE to compete with Microsoft Visual Studio. As a result a JSF based IDE called Sun Java Studio Created was created which was the most criticized and failed product from Sun Microsystems. This IDE was closed source, commercial and abandoned within 2 or 3 years. The source code was never published even after Oracle embraced open source policy. The failure of this IDE was mainly due to the bugs and defects in JSF specification and implementation.
ReplyDeleteJSF is not a pure MVC technology because it has view and controller mixed together.
JSF was not accepted as a Java EE technology until very recently. Still now JSF is useless, unless it is used with file products such as Omnifaces.
I am unable to accept that JSF is an enterprise technology.
Whether MVC1.0 is a Pull MVC Architecture or Push MVC Architecture please?
ReplyDeleteJava360