JCP EC 2016 Nomination

The Java Community Process (JCP) program 2016 Executive Committee (EC)
Elections have started. This is the first election to be held under the newest JCP 2.10 Process Document rules.

One of the new things introduced is that there will be two Associate Seats in the Expert Committee. These seats are elected by the Associate members of the JCP.

I have nominated myself for one of these Associate Seats. See my position statement below.

JCP EC 2016 Position Statement

The Future of Java EE May Be Bright After All

I don’t think anybody with the slightest interest in server-side Java™, and Java EE in particular, have missed the frustrations (and anger) in the community for the hiatus regarding the specification work of Java EE 8. The activity for most of the Java EE 8 targeted JSRs have more or less stagnated for almost a year, with only a few exceptions.

This has resulted in initiatives such as the Java EE Guardians and the Microprofile.io. Both emerging from a community eager to move Java EE forward to continue being the preferred platform for enterprise Java™.

The minutes from the August meeting in the JCP Executive Committee indicates that Oracle is finally beginning to move. At the meeting, Anil Gaur, Oracle Group Vice President with responsibility for Java EE and WebLogic Server, said:

“…We would like the future of Java EE to be viable to next generation of applications. These apps are composed and deployed differently in cloud and require flexibility, reliability and scale. The platform needs a new programming model that’s geared towards reactive style programming for building large-scale distributed applications that are loosely coupled…”

This year’s JavaOne will definitely be exciting in terms of Java EE. If you haven’t registered yet, do so!

I am carefully optimistic and think that Java EE has a bright future!

Java EE Security API Moving Forward

The Java EE Security API (JSR 375) is moving forward, as summarised by Arjan Tijms here: http://arjan-tijms.omnifaces.org/p/whats-new-in-java-ee-security-api-10.html.

One thing to note is that we now have a name for the reference implementation, namely Soteria. The name originates from Greek Mythology where Soteria was the goddess of safety and salvation [Wikipedia]. Our Soteria can be found on GitHub (https://github.com/javaee-security-spec/soteria) and also has a Twitter handle. Follow @Soteria_RI.

The Soteria GitHub repo contains a couple of samples that demonstrates the features implemented so far. I have created a couple of additional examples where I combine Soteria with other Java EE technologies, such as MVC and JSF. These can be found in https://github.com/ivargrimstad/security-samples.

As the following code shows, it is fairly straightforward to define an embedded identity store for an MVC 1.0 application.

@EmbeddedIdentityStoreDefinition({
    @Credentials(callerName = "hem", password = "cheese", groups = {"foo"}),
    @Credentials(callerName = "haw", password = "cheeze", groups = {"foo", "bar"})}
)
@DeclareRoles({"foo", "bar"})
@ApplicationPath("ui")
public class ApplicationConfig extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> classes = new HashSet<>();
        // add controllers
        return classes;
    }

The examples will be evolved as the specification and Soteria continues to evolve.

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:

Joining the Experts

I have been a member of the Java Community Process (JCP) for nearly ten years. My contribution so far has been to vote in elections and respond to surveys.

But recently this changed as I was selected to be a part of the Expert Group for JSR 371: Model-View-Controller (MVC 1.0) Specification. This JSR is targeted to be a part of Java EE 8.

I am looking very much forward to participating in this JSR and will post updates here now and then.