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:

http://bits.netbeans.org/download/trunk/nightly/latest/

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 (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
.

Saturday, March 19, 2016

NetBeans Java EE Tip #6: Create WebSocket Endpoint

The introduction of WebSocket support with the release of Java EE 7 provided a means for utilizing full duplex communication in your Java EE applications.  To utilize WebSockets, one must create an endpoint to which the client can connect for communication purposes.  NetBeans provides an easy-to-use wizard for developing WebSocket endpoints with a few clicks.

1)  Create your endpoint class.  First, select "New"->"Web"->"WebSocket Endpoint":
Figure 1.  Select WebSocket Endpoint

2)  Next, name your endpoint accordingly, provide a package into which the endpoint will be created, and also provide a WebSocket URI.  This is the URI that the client will connect to in order to send a message.


Figure 2.  WebSocket Endpoint Generation

3)  The NetBeans IDE will generate the initial WebSocket endpoint code.  All that is left to do is implementation of the onMessage() method to suit your application.



I will show you how to easily generate a client to communicate with a WebSocket endpoint using NetBeans in a future Java EE tip!

Friday, March 11, 2016

NetBeans Java EE Tip #5 - Custom Bean Validation Constraints

Bean Validation was added to the Java EE platform with the release of Java EE 6.  It brings a standard means of easily performing annotation-based validation to the platform.  There are several built-in bean validation constraints such as @NotNull, @Size, and @Pattern to name a few.  Please take a look at the Java EE documentation for a complete listing.

Sometimes there is a need to generate a custom bean validation constraint to suit the needs of an application.  In such cases, one must generate a custom validator class, as well as an annotation class for use with the validation class.  NetBeans makes it simple to do so, as it provides a wizard that produces skeleton classes that suit the specified criteria for your constraint.

To get started, right-click on the "Source Packages" node of your project or on an existing package, and choose "New"->"Bean Validation"->"Validation Constraint" (Figure 1).
Figure 1:  Select "Validation Constraint"

Next, choose a class name for the bean validation annotation class.  The name you elect to use will also be used for the annotation.  Provide a package name into which you wish to have the bean validation class created.  If you wish to have NetBeans automatically generate a validator class, then select the checkbox indicating as such.  If you elect to have the validator class generated, then provide a validator class name and a Java type to validate (Figure 2).

Figure 2:  Provide Class Name and Options

Once you click finish, the bean validation annotation class will be generated, as well as the validator class, if chosen.  You can then customize the class, as needed, to implement the validator.


Figure 3:  Generated Bean Validation Annotation Class

Figure 4:  Generated Validator Class with Custom Implementation

Once you've implemented the validator, it is ready to use.  As seen in Figure 5, simply annotate the field(s) that you wish to have validated.

Figure 5:  Utilizing the Custom Bean Validation Class



Recommended Reading on Bean Validation:

http://dataverse.org/files/dataverseorg/files/bean_validation.pdf?m=1448384482


Friday, March 04, 2016

NetBeans Java EE Tip #4 - RESTful Web Service JavaScript Client

In NetBeans Java EE Tip #3, I demonstrated how easy it is to create a RESTful web service using NetBeans.  In this tip, we will take a look at how quickly one can generate a JavaScript client for an existing RESTful web service.

To get started building the JavaScript client, right-click on the "Web Pages" folder of the NetBeans Web Application project, and choose "New"->"Web Services"->"RESTful JavaScript Client" (Figure 1).

Figure 1:  RESTful JavaScript Client

Next, provide a file name for the JavaScript file that will be generated for your client.  The wizard also allows you to choose a RESTful Web Service to utilize, and your choice of UI for the front end client site (Figures 2 and 3).

Figure 2:  Name JavaScript File & Choose Web Service

Figure 3:  Choosing Web Service

In Figure 4, you can see that I chose to use the Tablesorter UI for the front end. 

Figure 4:  Resulting UI Choice

Lastly, create the HTML page that will be utilized for your client.  Simply provide the name and optionally change the path to the file that will be generated.

Figure 4:  Name the HTML file

Once the wizard completes, your new HTML and JavaScript client will be ready to deploy and use!  

Figure 5:  HTML/JavaScript Client

The IDE will automatically reference the required JavaScript libraries to generate the client.  View the HTML sources, or click on the NetBeans project's "Remote Files" section to see which libraries are used.

Figure 6:  Remote Files in use by NetBeans Project

Friday, February 26, 2016

NetBeans Java EE Tip #3: RESTful Web Services from Database

Many modern web applications are moving towards the use of stateless communications using HTTP.  The REST (Representational State Transfer) architectural style is oftentimes utilized to design networked applications, and with Java EE 7 it is very easy to develop a RESTful backend for database communication.  Using a simple POJO (plain old Java object), one can provide a complete solution for stateless database communication by applying annotations to method signatures.

NetBeans allows developers to create RESTful solutions even more productively by providing tools such as the ability to generate RESTful Web Services from a database.  This allows a developer to select one or more database tables from which to generate RESTful web services without any coding at all.  Very similar to "Entity Classes from Database", this process takes it one step further and not only produces the required entity classes, but also a complete web service class for performing CRUD database operations in a RESTful manner.

To get started, right-click on your source package within NetBeans and choose "New"->"Web Services"->"RESTful Web Services from Database" (Figure 1).  This will open the "New RESTful Web Services from Database" dialog.
Figure 1:  Creating RESTful Web Services from Database

Figure 2:  New RESTful Web Services from Database Dialog

In this dialog, select the data source to which you would like to connect, and then choose one or more tables from the "Available Tables" list, and add to the list of "Selected Tables".  Choose "Next".  On the next dialog, you will have the ability to specify a package location, as well as which annotations to generate for your entity classes (Figure 3).

Figure 3:  Specify options for your entity classes

Next, you have the ability to specify the package location for your service classes.  The NetBeans wizard will also produce an ApplicationConfig class if one has not already been produced for your project, and place it into this resource package.  The ApplicationConfig is required to configure an access point for the RESTful web services in your application.

Figure 4:  Specify Resource Package Location

That's it...click "Finish" to generate the classes.  You will see that entity classes are generated for all of the database tables (and optionally those tables that are related).  In the elected resource package, web service classes are generated for each of the entity classes, and the ApplicationConfig class is also produced if it did not exist already (Figure 5).

Figure 5:  Classes Generated by Wizard

After following these procedures, you now have a completely usable web service for each of the database tables that you had selected.  These web service classes can be utilized to develop stateless applications that will communicate with your database.

Figure 6:  RESTful Web Service Class