A Comment on the Jigsaw Vote

Anyone who followed the discussions and comments about JSR 376 – Java™ Platform Module System, aka Jigsaw, the last couple of weeks, should not be very surprised by the result of the Public Review Ballot. As you can see below, 13 out of 23 EC Member voted no and 10 voted yes.

Please see the Ballot Result Page for details. Make sure you read comments in the vote log to understand the reasoning for the votes. Summarized, the two following comments seems to be trending:

  • The specification was not ready to move on as it was submitted
  • The discussions and progress during the 14 day ballot period shows that it is going in the right direction

Is this a bad think for Java™ 9?

I don’t think so. This is just an example that the process is working and that the JCP fulfills its role of ensuring the quality of Java™.

Will Java™ 9 be delayed by this?

Not necessarily. It gives the Expert Group an additional 30 days to respond to the comments from the EC before submitting for a Reconsideration Ballot. The actual release date is nothing that is controlled by the JCP.

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.

Join the Java Community Process

You have probably noticed that the Java Community Process (JCP) has made becoming a member much easier. There is a new membership level called Associate Member which does not require any paperwork or approval of your employer and it can all be done online filling out a simple form.

https://jcp.org

Why should you become a member?

– It looks good on your resume
– You can join as a contributor to any JSR and help evolve the Java ecosystem
– You get a vote in the upcoming elections for the Executive Committee

Why is the last item important?

Well, I am running for an associate seat in the EC, so by joining the JCP and voting for me in the upcoming election, you make sure that your voice is heard at the very top level of the JCP. My motivation is to give as much power to the community as possible.

Let’s make the JCP Great Again!

 

Please feel free to contact me on Twitter or discuss in the comment section if you have any questions or comments.

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

 

Aggressive Road Map for Java EE

After almost a year of silence, Oracle presented a preliminary proposed road map for Java EE. It is an aggressive one and will require dedicated hard work in the Expert Groups to make it happen.

There are some interesting new JSRs coming up regarding configuration and health check in addition to the changes going to happen in the existing ones. Worth noting is also that MVC 1.0 is left out entirely from this proposal.

On the other hand, also note that it is still just a preliminary proposal, and that we as a Community are invited to give our input through a new Java EE Community Survey.

Make sure to show your support by participating in this survey!

http://glassfish.org/survey

 

So, I am still optimistic and still believe that what I was hinting at in my previous post The Future of Java EE May Be Bright After All may actually come true!

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.

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