Thursday, September 15, 2016

NetBeans Java EE 8 MVC Plugin Enhancements

A while back, Geertjan Wielenga had posted about a NetBeans plugin that had been developed for the upcoming Java EE 8 MVC framework.  The plugin was originally developed by Manfred Riem, co-spec lead for JSR 371, and Geertjan had extended it to add functionality for viewing all of the MVC controllers within an application.  This plugin is a great start to a useful MVC plugin for NetBeans.

I've since taken the plugin and extended it further, adding the following enhancements:

  • NetBeans workspace now scanned to apply plugin only to those projects that contain MVC controller classes.
  • Ability to create a new MVC application which includes a basic controller class and corresponding view.
  • Ability to add new MVC controller class to a project.

Come and check out the new plugin functionality at JavaOne.  I have the honor of presenting along with Ivar Grimstad (JSR 371 Expert Group) and Gaurav Gupta (JPA Modeler) in the presentation UGF6435 -- Enterprise Modeling of MVC and Java EE Artifacts for NetBeans Day 2016.  I'll demo the plugin during the session, alongside the powerful JPA Modeler utility.  

Hope to see you there!

Friday, July 15, 2016

NetBeans 8.2 Profiler: Colored Results

One of the new features in NetBeans 8.2 is the ability to color profiler results differently based upon filters.  This can make things visually stand out, and easier to follow in the profiler output.

To enable colored profiler results, go into the NetBeans "Preferences"->"Java"->"Profiler" menu, as seen in Figure 1.  Check the box to "Use defined filters for coloring results".

Figure 1:  NetBeans Profiler Colored Filter Results

Add any filter(s) you wish, and assign a color to the results of those filters (Figure 2).  If you wish to display the output from one of the existing filters in a different color, click the tool icon and change the colors.  As you can see in the previous figure, I updated the Java EE Frameworks filter to be a green color.

Figure 2:  Assign Colors to Filters

After applying the colors to the filters, run the profiler and see the results!

Figure 3:  Colored Results!

Saturday, June 11, 2016

Help Move Java EE Forward

If you recall my post entitled Java EE 8:  What is the Current Status, it is apparent that the progression on Java EE has certainly slowed down over the past several months.  There are definitely some JSRs under the Java EE umbrella that have more activity than others, but Java EE as a whole has seen little to no movement forward since JavaOne 2015.  This is not something to be taken lightly by anyone in the IT industry.  Java EE is a critical part of the industry, as there are thousands of web applications that have been built using the Java EE stack.  There are probably even more applications that have not been built using the full Java EE stack, but still rely upon some of the Java EE technologies..such as the Java Persistence API (JPA) or Java Message Service (JMS).

Why is it so important to move things forward?  Why not just leave things how they are and let Java EE fade away?  Plainly put, these technologies need to move forward in order to remain secure and make use of the current API technologies of today.  If one wishes to simply let Java EE stagnate, that means that all of the applications and services utilizing all or part of Java EE (much of the internet as we know it) are also stagnating, and cannot be moved forward to stay current with today's technology and security concerns.

What can we do to try and help?  Move Java EE forward via the community.  If you have a few moments to spare, help move Java EE forward by sharing your expertise and contributing to one or more of the Java EE JSRs.  This can be done by joining the JCP (Java Community Process) and beginning to work on the code.  Work can be categorized in a number of can test existing code, document, debug, repair issues, or even develop features and enhancements for a Java EE 8 JSR.  Become a part of your local JUG and give a talk on Java EE 8, or get your JUG involved via the Adopt-a-JSR program and work with the JCP to help make improvements towards the Java EE 8 effort!

What can you do right now?  Sign the petition that has been proposed by the Java EE Guardians group to try and persuade Oracle to begin working on Java EE 8, once again.  The Java EE Guardians are a group of individuals/JUGs that are actively involved in trying to vocalize the current status of Java EE 8, in an effort to get the community involved and to make Oracle hear or opinion.  In the end, if Oracle is not interested putting forth effort internally and moving Java EE forward, hopefully they will be open to working more with the community, and hand off some of the specifications to those who are interested.

Thanks for reading the post...your time and participation is certainly appreciated!

Tuesday, May 31, 2016

NetBeans Java EE Tip #9: Create JSF Application from Database

Do you need to create an database front-end very quickly?  The NetBeans IDE allows one to develop a JSF application front end for a set of database tables very quickly, and with very little coding.  Now this tutorial is an oldie, but a goodie...and it is worth mentioning again for those who are not aware of it.

First, create your application.  In this case, I create a Maven Web Application by choosing "New Project"->"Maven"->"Web Application" (Figure 1).

Figure 1:  Maven Web Application

Next, I provide the web application name of JsfCustomers since I'll be making use of the CUSTOMERS sample database tables.  Once the application project is created, create a new Java package to hold the entity classes for the database.  In this case, I right-click on the project's "Source Packages" and select "New"->"Java Package...", and then name it org.jsf.jsfcustomers.entity  (Figure 2).

Figure 2:  New Java Package

After the package is created, right-click on it and select "New"->"Entity Classes from Database", which I've covered in a previous posting.  This wizard allows me to select a set of database tables from one of my I choose my sample database and select the CUSTOMER table.  After doing so, all related database tables are automatically added to the "Selected Tables" next (Figure 3).
Figure 3:  Create Entity Classes from Database

The next wizard page (Figure 4) allows me to select various options for generating my entity classes...I'll leave the defaults and click "Finish".
Figure 4:  Entity Class Options

After doing so, the entity classes for my database have been generated.  Now it is time to put the icing on the cake.  Since the database entity classes are now available, I can generate the entire JavaServer Faces infrastructure with just a few clicks.  Right click on the project's "Web Pages" folder and select "New"->"JavaServer Pages"->"JSF Pages from Entity Classes" (Figure 5).

Figure 5:  Create JSF Pages from Entity Classes

Next, select all of the entity classes that have been created, and click "Next" (Figure 6).

Figure 6:  Select Entity Classes

Lastly, specify options for creating your JSF classes and pages.  First, I specify a good name for my EJB session bean and JSF Controller packages.  The EJBs and controllers will be automatically generated into these locations.  Next, select the web folder where the JSF pages should be generated...leave blank for the root.  Lastly, I chose to utilize the PrimeFaces pages template to make use of PrimeFaces components.  Click next and choose the JSF configuration that has been previously registered with the IDE (Figure 7). "Finish" and see the magic...the web application and all of the JavaServer Faces infrastructure is generated automatically (Figure 8).

Figure 7:  JavaServer Faces Configuration

Figure 8:  Completed JSF Application

Note that you may need to right-click on your project "Dependencies" module and add PrimeFaces (Figure 9).

Figure 9:  Add Maven Dependency

Now build and run your application...and it is ready to use!

Thursday, May 12, 2016

Working with Mojarra Maven Builds

Some great updates have been made to the Mojarra repository in the past couple of months.  The JSF 2.3 Milestone 5 release has been available to download since March, and the Milestone 6 release is actively in progress.  Arjan Tijms and Bauke Scholtz have been actively contributing to the effort and moving things forward, which is helping Mojarra to maintain a healthy milestone cycle.

One of the biggest efforts that have been made was to complete the transition to Maven builds, rather than ANT.  The ANT build had become rather difficult to maintain over the years, and rather than going through the effort to repair it, the process has been changed over to a Maven build.  Manfred Riem, co-spec lead for JSF 2.3, had originally started this conversion to Maven and had nearly completed the effort, but never made it 100% of the way.  Arjan stepped in and finished the task so that it works with the latest milestones.

To begin working with the actively progressing 2.3 Milestone 6 along with the new Maven build, do the following:

Create a new clone of the Mojarra GitHub repository, or update an existing local repository from remote.

git clone

Once the clone is complete, execute the following commands within the terminal.  As you can see, you first move into the jsf-tools directory and build/install the artifacts using the mvn clean install command.  Next, move into the impl directory and issue the same command.

cd mojarra

cd jsf-tools

mvn clean install

cd ..

cd impl

mvn clean install

Doing so will create a Milestone SNAPSHOT JAR file in the <repository>/impl/target directory.  You can then start to test against the latest Mojarra sources and check out the newest features.

NetBeans Java EE Tip #8: Persistence Units

The foundational goals of any good IDE are to simply and organize one's code and development workflow.  NetBeans does a superb job of achieving these goals, and sometimes we take the basics for granted.  For instance, if your eyes have ever glossed over from trying to read XML in a plain text editor, you may have had issues configuring and working with Persistence Units in the past.  In case you aren't familiar with Persistence Units, they are XML configuration files that are used by a Java EE project to configure database connections and options.  NetBeans has a very easy-to-use persistence unit wizard, which will be showcased in this post.

For starters, NetBeans provides a wizard for generating a Persistence Unit for a project.  Simply right-click on a project, choose "New" from the context menu, and then choose the "Persistence"->"Persistence Unit" option.

Next, supply a name for your Persistence Unit, along with a Persistence Provider using the drop-down menu of selections.  You can then choose from an available Data Source, and choose a table generation strategy.

Once created, the Persistence Unit can be found within the "Configuration Files" folder of a NetBeans project.

Selecting and double-clicking the file will open the Persistence Unit editor.  NetBeans provides an easy to modify configuration screen for the Persistence Unit that allows changes to be made without working directly with XML.

For instance, one may wish to add an entity class for use with the Persistence Unit.  To do so, simply click the "Add Class" button and choose the desired class(es).

If you'd rather work directly with the XML of a Persistence Unit, choose the "Source" button at the top of the editor.  Rather than seeing drab XML, you will be presented with color-coded and an auto-completing XML document.

Working with history is a breeze with the Persistence Unit configuration within NetBeans.  Choose the "History" button at the top of the editor to see a listing of all changes made to the unit, and it also provides diffs so you can easily see the changes that have been made, and/or apply or revert code, as needed.

NetBeans provides and easy way to work with Persistence Units.  Forget about dealing with XML within a text'll never want to do that again.

Tuesday, May 03, 2016

NetBeans SQL Profiler - Take it for a Spin!

The upcoming release of NetBeans, currently in active development and testing, boasts plenty of new features.  A few of them include EMCAScript 6 Support, Docker Support, JavaShell Support, and SQL Profiling.  In the latest nightly builds, the SQL Profiler is now available for use, so I took it for a test spin.  In this post, I'll run through just a few of the options available with the upcoming NetBeans SQL Profiler...I think you will be quite pleased.

The SQL Profiler allows one to instantly see which queries are causing the most contention within an application, and enables easy comparison via total running time and invocations against each of the queries that have been executed.  The tool also allows one to perform heap dump, garbage collection in the profiled process, and many other useful features.

To get started with the SQL Profiler, download the latest nightly build of NetBeans, which can be done at the following URL:

Next, install and run the IDE, then import or select a project that utilizes a database.  Just like the other NetBeans profilers, a JVM must be calibrated for profiling before the SQL Profiler can be ran against a project that utilizes that JVM.  To perform calibration, select the project and then choose "Profile Project" from the "Profile" menu.  After a JVM has been calibrated, any project using that JVM can be profiled.  Simply select the project, and start the profiler of your choice by selecting the profiler option within the drop-down list.  In this case, I'll choose the SQL Queries option.

Figure 1:  Configuration Page

Figure 2:  NetBeans Profiler Selection Menu

Once the profiler has been started, the application will launch and the most current SQL queries will be displayed in a chart.  In this case, I am profiling a Maven based Web application project running Java EE 7 and JPA.  When the profiler is started, the web application launches and the SQL Profiler screen is displayed.

Figure 3:  NetBeans SQL Profiler Screen

The NetBeans SQL Profiler makes it easy to see which queries have been invoked, how many times they have been initiated, and how long they took to run.  As I run my cursor over the SQL queries, the query that is under my cursor is highlighted, and I am able to click on it to expand the row and see the method invocation stack.

Figure 4:  NetBeans SQL Profiler Method Invocation Stack for Selected SQL

If I choose, I can right-click on a given query, and view the SQL.

Figure 5:  Right Click on a SQL Row

Figure 6:  View SQL Query

As mentioned at the top of the post, I have the ability to perform a heap or thread dump for a selected query, and I can even perform a garbage collection.

The NetBeans SQL Profiler is going to be a great tool for anyone that develops applications utilizing a database backend.  Not only will it allow one to clearly see which SQL is causing the most contention within an application, but it also allows for easy comparison and provides detailed information on the underlying SQL invocations.

Download the latest build to try it out now...otherwise, it will be available with the public release of NetBeans 8.2.  The bonus is that if you try it now and find issues or have comments, you can help the developers make the Profiler even better.

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 (

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!