Friday, April 29, 2016

Java EE 8, What is the Current Status: Case Study for Completed Work Since Late 2015

For anyone who pays close attention to Java EE, it has become clear in the past six months that there has been a decline of activity...especially in those JSRs for which Oracle maintains the lead.  What's the deal?  There has been a lot of conversation in the Java EE community in this regard lately, and I think it is important that the developer community be given a fair timeline of what we can expect for the future of Java EE.  The uncertainty is becoming long in the tooth, and the community is becoming more concerned with the future of Java SE and Java EE as time goes on.

Let me give you a bit of background.  I'm an expert group member on a couple of JSRs targeted for Java EE 8, those being JSR 372 (JavaServer Faces 2.3), and JSR 378 (Portlet 3.0 Bridge for JavaServer Faces 2.2).  At the beginning of 2016, I had noticed that since October 2015 the number of emails on the Expert Group list for JSR 372 had really slowed down.   In fact, in the final quarter of 2015, the activity on JSR 372 had slowed down to a near halt, whereas it should be picking up momentum as time moves forward closer to the eventual final release.  In late January, I was contacted by a couple of members of the Java EE community, indicating that they also had seen a slowdown of activity and were very concerned.  I was then asked to join a community of concerned Java EE advocates on a Slack community...and when I joined and read the backlog of messages I could clearly see that it looked as though Oracle had stopped activity in just about every area of Java EE, specifically work on all of the JSRs that were Oracle-led.

I began to do some homework and started looking into the statistics a bit.  I wanted to see some clear evidence.  What I found is that in some JSRs, it was difficult to see a decline in activity on Oracle's part, but these JSRs, in particular, did not have a specification lead that was from Oracle.  Some JSRs, especially those not under Oracle's purview, are just overall more active than others.  On the converse, for those JSRs where Oracle does maintain the specification lead, the activity had almost come to a complete halt.  I'd like to share my findings for a couple JSRs, those being JSR 372: JavaServer Faces 2.3, and JSR 368: Java Message Service 2.1.

I gleaned the following information from the JSR 372 and JSR 368 public archives/records, including the JIRA (Mojarra JIRA and JMS JIRA), mailing list archives (JSR 372 EG Mailing ListJSR 378 EG Mailing List), and the GitHub repository (https://github.com/javaserverfaces/mojarra).

JSR 372 Statistics

First and foremost, I want to mention that the specification leads for JSR 372 are top notch, and they've done a spectacular job of leading the project.  That said, it seems that their activity has dropped off quite a bit since October 2015.  Here are some charts to display the data.

As I had mentioned previously, the JSR 372 specification leads have done a great job.  As such, they've still maintained a role in the email to the JSR 372 expert group mailing list.  That said, these numbers only reflect those through 03/2016...and there has not been much activity since.

If we take a look at the number of commits towards JSR 372 (captured from GitHub), we can see the there is a major decline in the work that has been done from Oracle.  Most of the work that has been done since October 2015 is from the community, mainly the most active JSF developers:  Arjan Tijms and Bauke Scholtz.

Another significant area of decline is in the number of issue resolutions from Oracle.  The following data was gleaned from Github, and the work from Oracle on JSR 372 since March 2016 is much the same.


The graphs above clearly indicate a decline in Oracle's involvement towards the eventual completion of JSR 372.  This is troubling because the work for JSR 372, as well as others encompassed in Java EE 8, is targeted for public release in less than a year (March 2017), and it seems as though that target is becoming more of a wishful goal now than an actual release date for Java EE 8.

JSR 368 Statistics

The statistics for JSR 368 show even more of a decline in activity from Oracle specification lead perspective.  Again, the spec lead has done a superb job leading the project until the changes seem to have been made in late October from the Oracle standpoint.

First, looking at the email, it is plain to see that there has been a drop off.  However, it seems that JMS 2.1 email has been slow for much of 2015.

 The number of commits for JMS 2.1 tell a different story, it looks as though there haven't been any commits done since late 2015.




As far as issue resolutions go, there has been little activity at all for the JMS 2.1 lifecycle.


That is all well and good, but comparing this data against the JMS 2.0 data is where there is a very clear indication that there is not as much effort going into the development of JMS for the 2.1 release.

The main purpose of this post is to alert the Java SE and Java EE communities that there has been a clear decline in the Oracle involvement towards Java EE 8.  I, like much of the rest of the community, am very concerned that the effort going into the Java EE 8 JSRs has declined at an alarming rate, seeming to indicate that this release is not ranking very high on the priority list.

That said, with the exception of the past year's activities, I think Oracle has done a fantastic job in the previous five or six years activating the Java SE and Java EE communities.  I have been proud to wear my GlassFish beanie and Oracle Java EE 7 t-shirts...letting everyone know how great it is to be a part of this community.  I enjoy speaking at conferences about the latest Java EE technologies, and writing posts to share the knowledge.

I think the rest of the community stands with me in saying that it would be good to have a clear statement from Oracle with regards to their intentions for the future of Java EE.  Not only would it help to clear the uncertainty that looms in the air, but it would also help the many customers and organizations that rely upon Java EE to have a clear understanding of what is to come.

I hope that we see activity pick up soon so that we can continue leading the way towards another significant Java EE release in the near future, maintaining the platform's edge when it comes to cutting edge technology.  Looking forward to hopefully seeing the Java SE and Java EE platforms continue to evolve long into the future!

Thursday, April 07, 2016

NetBeans Java EE Tip #7: Overlooked Java Class and XHTML Editor Shortcuts


Sometimes the most helpful features of an IDE are the most overlooked.  In this post, I will outline five NetBeans Java and XHTML editor shortcuts that can be used when developing Java EE applications.

#1 - Easily Fix Namespaces and Classes

Perhaps you have added a new JSF tag to a view for which the namespace has not yet been declared, or maybe you removed a tag that is no longer required, and the namespace is no longer needed.  NetBeans provides the SHIFT+CMD+I (OS X) and CTRL+SHIFT+I (PC) shortcuts to fix namespaces in the current file.  Much in the same manner, the same shortcut can be used in a Java class to fix all imports.  This shortcut enables easier management of namespaces in XHTML and imports in Java classes.

Figure 1:  Fix imports in Java Class


Figure 2:  Fix namespaces in XHTML



#2 - Autocompletion within XHTML and HTML

Sometimes it is easy to forget the name of that controller class when adding an EL expression to your XHTML view.  Other times we remember the name, but don't want to type out the entire path to the controller and method or property.  NetBeans provides auto-completion for Expression Language within XHTML files to remedy these issues.  Just start typing within an EL expression to see the auto-completion for all of the JSF controllers and/or properties/methods for the current project.


Figure 3:  Auto-completion in Expression Language

#3 - Quick Navigation to controller class or backing bean method

To quickly navigate to a JSF controller or property/method declaration that is referenced within an EL expression, simply hold down the CMD (OS x) or CTRL (PC) button and mouse click on the name.


#4 - Quickly Navigate to JavaScript

To quickly navigate to a referenced JavaScript function, hold down the CMD (OS x) or CTRL (PC) button and mouse click on the reference.
Figure 4: CTRL or CMD + click on function name

#5 - Navigate Directly to Stylesheet

To quickly navigate to a CSS Style, hold down the CMD (OS x) or CTRL (PC) button and mouse click on the "id" or "class" attribute of the element that is referencing the style, and a drop-down list of all matches will be displayed



Figure 5:  CTRL or CMD + click on "id", "class", or "styleClass" attribute
.