[jax-rs-spec users] Re: [jsr339-experts] MVC

From: arjan tijms <>
Date: Tue, 1 Jul 2014 00:43:50 +0200

On Mon, Jun 30, 2014 at 9:11 PM, Joshua Wilson <> wrote:

> No, I think the driving factor is the existence of Spring MVC.

I appreciate the openness to clearly state that you think this is the
driving factor. Right in the beginning I picked up various signals about
this too, but nowhere was this really made explicit.

If the goal is to have Spring MVC (Spring MVC like API) in Java EE and not
a specific use case, then at least this is clear point to start discussing
from. You may have guessed that I wouldn't agree with it ;), but it's a
good point to start the discussion.

I think that the community sees JSF as difficult due to it's early issues
> and they do not equate it to Spring MVC.

Nobody will deny that JSF had severe early problems. The content
interweaving issue, the one-URL behind problem, the many moving parts
required to implement a custom component and the strong focus on POST-only,
combined with a not yet mature offering of component sets did all not
contribute to much love for JSF.

However, as I've explained before and a couple of others have as well, this
all changed rather radically with the release of JSF 2.0. Before that there
was an "I hate JSF blog" pretty much every week. After JSF 2.0 became known
this stream pretty much dried up, I guess for lack of ammunition.

For instance, the argument: "but JSF components are so difficult to
create!" basically evaporated with the introduction of composite components
and the simplification of creating Java based custom components. See for
example the following blog post I wrote about this: It's a far
cry from the work that needed to be done in JSF 1.x. And still, as simple
as it currently is, there's still some room left to make it even simpler.

Currently what I see as a recurring pattern is that someone on a forum or
site like Reddit who has obviously not touched JSF since 1.x will complain
about e.g. JSF being POST only, not having something like The Flash, etc
and then a few other users immediately pointing out that all of this has
been addressed years ago and that JSF 2.x works like a charm.

You basically have two groups of users thus; those who know about JSF 2.x,
and those that only knew 1.x. The former group is getting bigger every day,
while the latter is continuously shrinking.

With a continuous effort on making the JSF core even simpler and at the
same time more powerful, combined with efforts from the JSF ecosystem (like
PrimeFaces, RichFaces, and hopefully my own and Bauke's contribution of
OmniFaces among others), I think we can only increase the speed with which
that former group is growing and that latter one is shrinking.

Therefor they desire a "Spring MVC" like API/SPI in Java.

I personally don't see that the larger community desires this. As I pointed
out earlier in this discussion (see
the evidence does not really support the thesis that a majority of users
use Spring MVC.

If we can conclude anything from the sources I looked at, it's perhaps that:

1. The web framework market remains highly fragmented
2. Both Spring MVC and JSF are among the top ranked and most frequently
used frameworks

If Java EE would have shipped with a framework that's often at the very
bottom of those polls and surveys (as EJB 2 once was), while Spring MVC
would consistently be at number 1 with a large margin, then it would be
rather clear cut. But as the evidence shows, this is far from the case.

Maybe Spring MVC has a user base that has a vocal minority that's very
actively advocating the technology, but so do many of the other web

And there's people who say they don't like Spring MVC as well, e.g.

"[Spring MVC] is more difficult to work with and less productive than JSF
and CDI now" (

"I had to work with [Spring MVC] in 2008 and it wasn't much more than
standard JSP. I thought it was an abomination to work with"

"Just looking at a Spring MVC tutorial to see what it's about again. First
though; oh yeah, this nonsense. Every controller is almost a Servlet, also
with low-level Servlet things exposed in a kind of backing bean"

And when looking at some code that was given at the above link as an
example of why Spring MVC would be simpler, we see the following:


public class AppointmentsController {

    private final AppointmentBook appointmentBook;

    public AppointmentsController(AppointmentBook appointmentBook) {
        this.appointmentBook = appointmentBook;

    @RequestMapping(value="/new", method = RequestMethod.GET)
    public String getNewForm(Model model) {
        model.addAttribute("appointment", new Appointment();
        return "appointment-edit";

    @RequestMapping(value="/new", method = RequestMethod.POST)
    public String add(@Valid Appointment appointment, BindingResult result,
RedirectAttributes redirectAttributes) {
        if (result.hasErrors()) {
            return "appointments/new";
        redirectAttributes.addFlashAttribute("message", "Successfully added
        return "redirect:/appointments";



public class NewAppointmentsBacking {

    private AppointmentBook appointmentBook;

    private Appointment appointment = new Appointment();

    public String saveUser() {
        addFlashMessage("Successfully added " + appointment.getTitle());

        return "/appointments?faces-redirect=true";

    public Appointment getAppointment() {
         return appointment;

Just some example that people actually used. I'm not sure whether the
Spring MVC controller is really simpler, and this is for a rather common
use case. The link above also gives a somewhat more uncommon example of
rendering an image from memory, but there too the Spring MVC code as
demonstrated is not clearly simpler than the JSF code. In fact, I'd argue
that the JSF code is simpler (of course I'm biased knowing JSF better than
Spring MVC, but still).

At any length the difference in code complexity and amount of lines of code
as demonstrated by these examples is a FAR cry from the difference we once
saw between EJB 2 session beans and Spring Beans, and between EJB 2 entity
beans and Hibernate. That was a huge day and night difference. In this
case, I don't know. As someone else on this list said, there are probably
more similarities than differences, and a lot of the differences shown here
for typical use cases are more stylistic in nature than anything else.

1) Do we create a new action based MVC spec?
> 2) Do we change JSF?
> 3) Do we let Spring MVC continue as the dominate player in the action
> based MVC arena?
> My preference is for number 1. Though I think Bill Burke has an
> interesting idea that might be worth considering about just creating an SPI
> for all other MVC frameworks to adhere to. (I need to think more on that
> one.)
> Personally I do not think 2 is an option. And it appears the community
> does not want 3.

I think number 2 is always an option. There are plenty of things on the JSF
issue tracker (not necessarily all related to the action-oriented effort)
that in general aim to make JSF even simpler.

I wonder about 3. Why would the community not want this? Why don't they
just use Spring MVC if they want Spring MVC? What if people just want to
use Spring because it's Spring, and if Java EE (Oracle in their eyes)
includes a Spring MVC clone, wouldn't they be wary of using that because of
some possible bias against Java EE (maybe because of a bad experience with
J2EE 1.4) that made them choose Spring in the first place?