JSR371

JCP Star Spec Lead 2018

Wow, what a year 2018 was for the MVC specification!

I know we are well into 2019 now and that I did sum up 2018 in early January. In that post, I mentioned that Christian and I received the JCP Outstanding Spec Lead Award at the JCP party for our work on JSR 371. At the same ceremony, Daniel Dias Dos Santos received the Outstanding Adopt-a-JSR Participant Award, also for his work on JSR 371.

And to top it all, Christian and I were announced as 2018 Star Spec Leads. Read more about the Star Spec Lead Program. 

A complete list of all Star Spec Leads can be found in the Star Spec Lead Hall of fame.

Ozark becomes Eclipse Krazo

One of the requirements for Eclipse Projects is that the name is not associated with any trademarks or potential trademarks. When we created the project proposal for Ozark, this turned out to be the case here. The name Ozark is simply used too many places for it to be a valid Eclipse project name.

So, how did we come up with the new name? First of all, we asked for input on the Ozark developer mailing list. We also wrote a small program that generated all permutations of ‘ozark’ to see if something cool came out of that.

public static void main(String[] args) {
    new Permutations().permutations("ozark").stream()
            .forEach(System.out::println);
}

Then we started filtering, discussion and voting until we ended up with Krazo, which turns out to be Ozark spelled backward. We are really excited about the new name and hope you all will join us in spreading the word that the reference implementation of MVC 1.0 that was previously known as Ozark is now called Eclipse Krazo.

MVC 1.0 goes to Eclipse Foundation

Last year when waiting for my flight home from JavaOne, I blogged Possible Ways forward for MVC 1.0. Now, I am sitting here at SFO again writing a follow-up on that article.

As we all now, the JSR was was transferred to me from Oracle to be completed as a standalone JSR. Since then, Christian Kaltepoth has joined me as specification lead. We never did anything about the actual IP, all in full agreement. After all, we are developers and not lawyers and just wanted to get going with the actual work.

It has never been my intention to capitalize on the IP, and I wanted to figure out a way to donate it all back to the community. As those of you who follow the EE4J Community Mailing List probably noticed, I announced the intention to transfer MVC 1.0 to Eclipse Foundation. Read the announcement here:

https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00106.html

This does not imply any changes to the current specification work, expert group or time plan. There may be some practical changes, such as a new mailing list and moving the repositories under the Eclipse GitHub Organization, but that is way in the future.

So why Eclipse and not Apache?
Well, it makes sense to follow the other Java EE technologies when they are transferred to the EE4J umbrella project in Eclipse Foundation. MVC would be a natural fit there, but the exact details will be handled by the EE4J PMC.

 

 

MVC 1.0 is Back!

When Oracle announced that MVC 1.0 was withdrawn from Java EE 8, they also indicated that they were investigating a possible transfer to a community member or organization for completion as a standalone JSR. True to their word, a request for a transfer ballot of JSR 371 has now been submitted to the JCP Executive Committee.

I am happy to announce that I will be the receiving part of this transfer and thus will take over as Spec Lead for JSR 371.

So, why would I want to take over a JSR that ranked so low in the Java EE Survey?  Well, there are several reasons for that:

First of all the incredible community support and interest there is for MVC 1.0. For example, JSR 371 is the most widely adopted JSR by Java User Groups participating in the Adap-a-JSR program. No less than 8 JUGs have adopted this JSR!

Secondly, I feel that the wording of the question in the survey may have played a role. The question for MVC was “How important is MVC API for the next generation of cloud and microservices applications? (1=Not Important, 2, 3, 4, 5=Very Important)”.  Still, 505 responded Very Important and only 361 Not Important. The rest were pretty evenly distributed. See Java EE Survey Results for the complete numbers.

Third, only 1693 surveys were completed worldwide. Out of 10 million Java developers, this is an alarmingly low number taking into consideration that the survey was open for more than a month and there were massive encouragements for participation from the community, including Oracle.

Fourth, in the Java EE Guardians survey that was performed just prior to the Java EE 8 survey more than 30% of the respondents answered Very Important to the question “How important is it to add a new action-oriented MVC framework to Java EE?”.

The Way Forward

The most important thing right now is that the request for transfer is approved by the EC. The ballot closes January 30, so shortly after that the practical work may start.

Possible Ways forward for MVC 1.0

As mentioned in Aggressive Road Map for Java EE 8, MVC 1.0 is left out of the plans for Java EE 8.

The way I see it, and also have indications from several people I have talked with during JavaOne, the possible outcomes of this are:

1. MVC is dropped completely
2. MVC continues and is included in Java EE 8 (JSR 366)
3. MVC continues as a standalone specification outside of the Java EE 8 umbrella spec

Let’s cross our fingers that the survey result turns out positive for MVC and that option 1 is ruled out by the community.

If we’re honest, option 2 is probably not very likely to happen. Given the aggressive road map for EE 8, cuts will need to be made. And MVC certainly isn’t on the list of the preliminary proposal.

Then we are left with the third option. And I actually think this may be the best way for MVC. There are several reasons for this:

Release Cycle

MVC will not be depending on the Java EE 8 release and may release earlier and more oftenJava EE 8 is going to include some form of modularity and MVC may very well be one of these modules no matter if left out of EE 8. There are also some considerations to take if this option is explored

Portable RI

Ozark needs to be made portable across Java EE implementations. This means that we will need to get rid of the dependencies on internal Jersey APIs and base the entire implementation on APIs and SPIs that are available in Java EE 7 (and later Java EE 8 and 9)TCK

Licensing

An open TCK under for example Apache 2.0 will enable us to easier use community input for developing the TCK. If Oracle is willing to let go of the TCK, they will also be relieved of the cost of creating it. This actually also applies to Ozark. It would be great if it could be developed under e.g. Apache 2.0

So, what you should do is to fill out the survey by following the link below:

http://glassfish.org/survey

 

MVC 1.0 Generator

The JPA Modeler plugin for NetBeans provides visual support for creating, designing and editing entity relationship models. It also provides Java code generation and new for version 1.5.5 is that it provides support for generating MVC 1.0 applications.

Check out MVC 1.0 Generator Tutorial to see how it works.

JSP

Kudos to Gaurav Gupta (@jGauravGupta) for this awesome tool! Another proof that NetBeans is the IDE for developing Java EE applications!

Follow @jpamodeler on Twitter!

Cool Security Feature in MVC 1.0

If you are developing web applications, sooner or later you will come across something called Cross Site Request Forgery. The most common way to prevent CSRF attacks is by embedding additional, difficult-to-guess data fields, or tokens, in requests containing sensitive data.

Support for CSRF protection has been added to the MVC 1.0 specification. It goes like this:

First, enable CSRF Protection in your application configuration by setting the javax.mvc.security.CsrfProtection to either CsrfOptions.EXPLICIT or CsrfOptions.IMPLICIT.

@ApplicationPath("mvc")
public class MyApplication extends Application {

    @Override
    public Map<String, Object> getProperties() {
        final Map<String, Object> map = new HashMap<>();
       
        // explicit CSRF Protection
        map.put(Csrf.CSRF_PROTECTION, Csrf.CsrfOptions.EXPLICIT);
        return map;
    }
}

Then add the CSRF token to your forms. The Csrf object is available in Expression Language as mvc.csrf .

<form name="form" action="" method="post">
   ...
   <input type="hidden" name="${mvc.csrf.name}" value="${mvc.csrf.token}"/>
</form>

If CsrfOptions.IMPLICIT is used, you’re done. All controller methods annotated with @POST and that consumes the media type x-www-form-urlencoded will be automatically checked for a valid CSRF token.

If CsrfOptions.EXPLICIT is used, then the  @CsrfValid annotation must be added exlicitly to the methods you want the CSRF token to be validated.

@CsrfValid
@POST
@Path("new")
public Response createReservation(@BeanParam FormBean form) {
   // your controller implementation
}

And that’s all you need!

An update from JSR 371 (MVC 1.0)

The work in the Expert Group for JSR 371 progresses and here is a small update. A couple of decisions have been made and the most important one is that the JSR will be layered on top of JAX-RS. The decision was made by voting between this and the alternative of layering it on top of the Servlet API.

What this means for you as a developer is that the stuff you are familiar with from JAX-RS is directly transferable to MVC. As you can see in the simple example below, the only thing that differs from JAX-RS is the @Controller and @View annotations.

Note that this code is highly experimental and will most likely change as the work with the specification continues.

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;

import javax.mvc.Controller;
import javax.mvc.View;

@Path("count")
public class CountController {

   @GET
   @Controller
   @Produces("text/html")
   @Path("{id}")
   @View("counter.jsp")
   public void view(@PathParam("id") String id) {
   }
}

A more complete example with a little more details can be found at https://github.com/ivargrimstad/mvc-samples. I will continue evolving this example as we go.

The latest versions of the spec and reference implementation can be found here:

2014 Conferences

I know it is a bit early to sum up the year in November, but since I have not planned any more conference talks this year I think I will do it anyway. As the picture shows I have been pretty active this year.

 

2014-11-08 12.15.31

I have been presenting at conferences in Norway (Software 2014), Sweden (Javaforum, Øredev), Germany (Javaland), Poland (JDD), Ukraine (JEEConf, JavaDayKiev) and Morocco (JMaghreb). In addition to my speaker appearances, I was also able to attend JavaOne in San Francisco where I got to meet a lot of people in the JCP and ended up being selected to the Expert Group for JSR 371 – MVC 1.0.

I hope to continue speaking at a lot of conferences next year as well. Talks have already been accepted by jDays and Javaland, so it looks promising.