BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Public Review of Java MVC 1.0 Specification is Now Open

Public Review of Java MVC 1.0 Specification is Now Open

Bookmarks

Public review of JSR-371, Model-View-Controller (MVC) version 1.0 specification, is now open. This is the first major release since Oracle transferred ownership to Ivar Grimstad in April 2017. Christian Kaltepoth, senior software developer at Ingenit GmbH, joined Grimstad as co-specification lead shortly after the transfer. JSR-371 was subsequently licensed under the Apache License 2.0, and in October 2017, Grimstad announced his intent to transfer MVC 1.0 to the Eclipse Foundation after its final release.

New features since the Early Draft Review 2 include:

  • Internationalization - supports I18N.
  • Improved data binding - enables MVC-specific rules for data binding and validation using the @MvcBinding annotation and the BindingResult class.

As listed in the specification documentation, the goals of MVC 1.0 are:

  • Leverage existing Java EE technologies.
  • Integrate with CDI (JSR-346) and Bean Validation (JSR-349).
  • Define a solid core to build MVC applications without necessarily supporting all the features in its first version.
  • Explore layering on top of JAX-RS for the purpose of re-using its matching and binding layers.
  • Provide built-in support for JSPs and Facelets view languages.

The Eclipse Ozark project for EE4J provides a full implementation of JSR-371 that supports RESTEasy, Jersey, and Apache CXF. It is anticipated that Ozark version 1.0 will be released in the second quarter of 2018 in conjunction with the final release of JSR-371.

Getting Started

The @Controller annotation defines an MVC 1.0 controller as shown below with a very simple example that renders a JSP file:

    
@Path("hello")
@Controller
public class HelloController {

    @GET
    public String view() {
        return "hello.jsp";
        }
    }
    

The method return types in an MVC 1.0 controller class are handled in various ways. For example:

  • void - must be decorated with the @View annotation (see example below).
  • String - returns a path to a view (see example above).
  • JAX-RS Response - allows full access to an HTTP response including the headers (see example below).

Shown below is a typical example of an MVC 1.0 controller (from the hello-cdi example in Grimstad's GitHub repository):

    
@Path("hello")
@Controller
public class HelloController {

    @Inject
    private BindingResult br;

    @Inject
    private Messages messages;

    @Inject
    private HelloBean helloBean;

    @GET
    @View("form.jsp")
    public void form() {
        }

    @POST
    public Response formPost(@Valid @BeanParam HelloForm form) {

        if (br.isFailed()) {
            messages.setErrors(
                    br.getAllValidationErrors().stream()
                    .collect(toList()));

            return Response.status(BAD_REQUEST).entity("form.jsp").build();
            }

        helloBean.setFirstName(form.getFirstName());
        helloBean.setLastName(form.getLastName());

        return Response.status(OK).entity("hello.jsp").build();
        }
    }
    

Autowired into the controller are instances of BindingResult (for validation) and models, Messages and HelloBean, using the @Inject annotation. The view will render form.jsp, as specified in the form() method, annotated by @View. The method formPost() returns type Response and handles validation. The HelloForm class defines string lengths for user input validation:

    
public class HelloForm {

    @MvcBinding
    @NotNull
    @Size(min = 1, max = 16)
    @FormParam("firstName")
    private String firstName;

    @MvcBinding
    @NotNull
    @Size(min = 2, max = 24)
    @FormParam("lastName")
    private String lastName;

    public String getFirstName() {
        return firstName;
        }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
        }

    public String getLastName() {
        return lastName;
        }

    public void setLastName(String lastName) {
        this.lastName = lastName;
        }
    }
    

The specification documentation describes the process of binding and validation:

Parameter bindings such as @FormParam and @QueryParam may be annotated with @MvcBinding to enable MVC-specific binding rules. For MVC bindings a failed validation does not result in a ConstraintViolationException being thrown. Instead, the corresponding ConstraintViolation is stored in a request-scoped instance of BindingResult which can be injected into the controller. This allows the controller to handle the error instead of relying on a global error handling mechanism like an ExceptionMapper.

Running the hello-cdi example application presents the user with the following page after being rendered by form.jsp:

User input, as shown below, satisfies the string length validation and renders hello.jsp:

Shown below is the result of a validation error which, in this example, will clear out the input and display the error messages:

Grimstad, principal consultant for the Cybercom Group, spoke to InfoQ about this latest status of MVC 1.0.

InfoQ: Why did Oracle drop support for MVC 1.0?

Ivar Grimstad: This is actually something for Oracle to comment on. My understanding of the reasoning for Oracle's decision to drop MVC 1.0 from the scope of Java EE 8 was that they perceived MVC to be irrelevant for cloud applications since they usually ship headless.

InfoQ: When do you anticipate MVC 1.0 being integrated into EE4J? What needs to be done before that can happen?

Grimstad: We have already created a project proposal for Ozark, the reference implementation of MVC 1.0. The project proposal can be seen here: https://projects.eclipse.org/proposals/eclipse-ozark

We expect to integrate the rest of MVC 1.0 into EE4J shortly after we have released version 1.0 through the JCP. The plan is that we should be able to do that some time during Q2 this year. The reason why we have chosen to do it this way is that we want MVC to have reached the Final Release status before being transferred.

InfoQ: With APIs such as Rest Client 1.0 and JAX-RS 2.0 that are integrated into MicroProfile 1.3, would the MVC 1.0 API be a natural fit for MicroProfile?

Grimstad: Technically, you can run MVC 1.0 applications on top of MicroProfile. However, since the objective of MicroProfile is to optimize Enterprise Java for microservices, I am not sure if MVC actually fits in under the MicroProfile umbrella. It is a complementing technology and since it is running on the same stack it works very well together. A better home for MVC will be under the EE4J umbrella.

InfoQ: What's on the horizon for MVC 1.0?

Grimstad: The next thing up for MVC 1.0 is the Public Review Ballot which will take place between February 6-12. After that we will continue the work of finalizing the specification. The current plan is to have a final release in Q2 2018.

Our progress and ways to contribute can be found here:

InfoQ: What are your current responsibilities, that is, what do you do on a day-to-day basis?

Grimstad: On a day-to-day basis I work as principal consultant for Cybercom Group in Sweden. I do write code on a daily basis and stay up-to-date on current technologies by participating in open source projects and speaking at conferences. I am in the Executive Committee in the JCP as well as the PMC for EE4J.

Resources

Rate this Article

Adoption
Style

BT