Showing posts with label JavaFX. Show all posts
Showing posts with label JavaFX. Show all posts

Wednesday, November 26, 2014

Cannot Uninstall JavaFX SceneBuilder 1.0 with JDK 8

I was recently removing some of the software development applications, tools, and files I had used from an old Vista-based laptop because the people who are primarily using that laptop now have no interest in software development. As part of that effort, I tried to remove JavaFX Scene Builder 1.0, which I had installed a couple of years ago on that laptop. I hadn't used it recently (JavaFX Scene Builder 2.0 is available) but I had not removed the version from the laptop when I stopped using that old version.

My first attempt to remove JavaFX Scene Builder 1.0 was via the Windows Vista menu option Control Panel | Programs | Uninstall a program. The next screen snapshot shows this version of JavaFX Scene Builder 1.0 that I wanted to install along with the version of Java installed on that machine (JDK 8 and Java 8 JRE). No versions of Java (JDK or JRE) before Java 8 were on this machine.

The next screen snapshot demonstrates the normal requested confirmation of the removal of JavaFX Scene Builder 1.0.

Clicking the "Yes" button on the confirmation dialog just shown led to the removal process beginning.

Unfortunately, the removal of JavaFX Scene Builder 1.0 aborted and showed the error message: "No suitable 32-bit Java Runtime Environment (JRE) has been found. You should install Java 6 Update 29 (32-bit) or above OR Java 7 Update 2 (32-bit) or above."

I was a bit surprised that JavaFX Scene Builder could not be uninstalled with a Java 8 JRE installed on the machine. I tried to uninstall it more than once to make sure, but it was resistant to removal with only JRE 8 installed. I ended up simply removing the JavaFX Scene Builder 1.0 directory with Windows Explorer as shown in the next screen snapshot.

Because I could not use the uninstaller to remove JavaFX Scene Builder 1.0, I also needed to manually remove the shortcut as shown in the next screen snapshot.

It was not a big deal to remove the directory and shortcut when the installer was unable to remove JavaFX Scene Builder 1.0 from this machine. It also would not have been too difficult to download and install a Java SE 7 JRE to use in uninstalling JavaFX Scene Builder. However, I was a bit surprised that it was written so that an appropriate version of JRE 6 or JRE 7 was required. It explicitly prevents JRE 8 or any future JRE from being used to uninstall it.

I saw this same type of situation recently with a different tool in a different environment. In that case, the version of SQLDeveloper being used would only work with a certain specified range of updates for Java SE 6 and not for any Java SE 6 updates outside of that range and not for any versions of JDK 7 or JDK 8.

Conclusion

There is a software development reminder (or lesson to be learned) from this. It is easy as humans to think only about the current timeframe and about the past, but we as software developers should put some thought into what the future holds. The prevailing version of software is not always going to be the prevailing version and when our software's documentation or the software itself advertises supporting certain versions "and above" or "and later," then we should probably not put an explicit check in our code that forces the software to have the one of the expected major revisions or that caps the supported versions.

Thursday, February 14, 2013

Miscellaneous Musings about RMOUG Training Days 2013

I was only able to attend a portion of Rocky Mountain Oracle Users Group (RMOUG) Training Days 2013, but this was my 13th year to attend all or part of this conference (and my 11th year presenting). I have always enjoyed meeting and talking to the people who attend even as my interests have diverged somewhat from the database-focus that formerly aligned so well for me with the conference. As I have posted on before, this year's conference had a lot of focus on mobile application development in addition to the normal breadth and depth of database-oriented topics. In this post, I look at some of the excellent questions (and my responses) I was asked at my presentation on JavaFX and Groovy and look at some other things I learned while attending.

JavaFX and Groovy

I started my session at 2:45 pm with about 10 people in attendance, but the audience reached about 25 people in size by the end. It was another good RMOUG Training Days audience with good questions that made me think they were understanding what I was trying to convey. I'll address some of those questions with my responses now.

One audience member asked how it worked in the JavaFX example that the overridden start method was never called from the static main function of the application. I explained that the same application class extends javafx.application.Application and, thanks to that inheritance, the start(Stage) method is invoked automatically as part of the JavaFX application lifecycle. That start(Stage) method is declared abstract in Application so concrete child implementations must inherit it. Only a call to one of the Application.launch methods was seen in my example, but the start(Stage) method overridden in the child class gets called via polymorphism during the application's execution.

Another question asked in my presentation had to deal with Oracle's use of JavaFX in their own tooling options such as JDeveloper, Oracle ADF, and the like. I obviously do not know the extent of this, but I was happy to speculate that Oracle would like to use JavaFX in more internal tools to leverage their investment in it. One attendee wondered if some of the Oracle ADF-based mobile applications shown in other sessions of this conference used JavaFX underneath. I don't know enough about that to confirm that.

Although I did not demonstrate it in my presentation, I did mention the availability of SceneBuilder. I also mentioned that while other IDEs such as JDeveloper can support JavaFX, NetBeans appears to be the current leader in JavaFX support.

One or two questions surrounded JavaFX's place in the competitive landscape. I attempted to contrast it with Flex, Silverlight, HTML5, Swing, other languages' graphics libraries, and other native mobile development platforms. In some ways, the determination of what JavaFX is competing against is based on how one wants to use it. In desktop applications, the most common "competitors" are pure Swing (without JavaFX), pure SWT (without JavaFX), Adobe AIR, and other languages' graphical libraries. In web application, obvious "competitors" are HTML5/jQuery and Flex. On mobile applications, obvious competitors include the web stack as well as native languages such as Objective-C for the iOS devices. It could be argued that it's a good thing that JavaFX has or soon will have so many different platforms to compete on, giving JavaFX developers flexibility to apply their skills easily to multiple platforms.

I talked about GroovyFX's support for concurrency as provided in the javafx.concurrent package and I referenced the Concurrency in JavaFX article. An audience member asked about Groovy's support for concurrency. I responded to this by briefly discussing gpars and explaining that gpars (Groovy Parallel Systems) is now bundled with Groovy (since Groovy 1.8).

Additional questions were asked that were, I thought, insightful, but I am not talented enough to write them down and respond to them at the same time and have now temporarily forgotten some of the others.

Before leaving coverage of my own presentation, I want to include two slides that I showed in the presentation and in a "slide show" that I had running while waiting for the start time to arrive. These slides summarize some key moments in the history of JavaFX and history of Groovy.

Thinking back upon the history of JavaFX and Groovy, it is easy to see some similarities between the two. Both started with significant enthusiasm that then seemed to wane for a while before resurgent interest and coming back stronger than ever. It seems to me that SpringSource has been a pivotal player in providing stability to Groovy and making it more popular than ever and Oracle has done the same for JavaFX (deprecating JavaFX Script and embracing standard Java APIs was bold but well played).

Oracle Fusion Application Development

I was able to attend Ann Horton's presentation "Web Development Techniques from an Oracle Fusion Applications Developer." Ann's presentation was filled with screen snapshots, making it easy to see how to use the graphical-based tools to build Oracle Fusion Applications and use Oracle Fusion Middleware. I don't have any experience with Oracle Applications, but a lot of people do. Although I probably won't have the opportunity to work with them anytime soon, I like to see what other technologies are out there and enjoyed seeing a different way of developing applications. As is the case with much of the software development that occurs, Oracle provides tools that make much of the creation drag-and-drop and selecting things with the mouse.

Ann described "Oracle Fusion Applications Suite" as the "next generation of Oracle Applications" and added that "Fusion" implies integration of multiple products "under a common umbrella and one look and feel." Ann showed via numerous screen captures (often annotated with arrows, underlines, or other markings to provide focus) how to build up an application using Oracle Fusion Applications Suite.

One of the things I like to do at a technical conference is find out what others are using for tooling. Ann mentioned that thousands of developers have worked on Oracle Fusion Applications Suite and that they have used tools such as ade (Application Development Environment), JUnit, Selenium, OATS, and JAudit in their work. I thought it was interesting that JSP and JSF fragments (.jspx and .jsff files) were shown in the presentation.

Ann talked about Fusion developers using and providing "Fusion Guidelines, Standards, and Patterns" (GPS). More details about the Oracle Fusion Applications can be found in Oracle Fusion Applications Developer's Guide.

Oracle ADF and Mobile Development

Until I read the abstracts for this conference, I had not even realized that Oracle ADF can be used to develop applications for iOS and Android devices, but the subject of Oracle ADF Mobile was a popular one at the conference. The main page for Oracle ADF Mobile describes it like this:

Oracle ADF Mobile is an HTML5 and Java mobile development framework that enables developers to build and extend enterprise applications for iOS and Android from a single code base. Based on a hybrid mobile architecture, ADF Mobile supports access to native device services, enables offline applications and protects enterprise investments from future technology shifts.

The Oracle ADF Mobile FAQ states that Oracle ADF Mobile is licensed "as part of the Oracle Application Development Framework (ADF)" and adds that "Oracle ADF can be licensed either as 'Oracle Application Development Framework and TopLink' item on the technology price list, or as part of the Oracle WebLogic licenses." The FAQ also addresses device support: "Both iOS (5.x and above) and Android (2.3.x and above) devices are supported. Furthermore, both the tablet and smart phones running these mobile operating systems are supported."

One of the audience members asked me how using JavaFX differed from using Oracle ADF Mobile and licensing is obviously one of the major differences.

Other Blog Posts on RMOUG Training Days 2013 Conclusion

I would have liked to attend more sessions at RMOUG Training Days 2013, but enjoyed the brief time I was able to spend there this year. It was good to see people I've known for a number of years and to meet new people. It is always good to remember that there is much more to software development than the relatively narrow view one can get when working in the same circles and communities all the time.

Wednesday, February 13, 2013

Styling JavaFX Pie Chart with CSS

JavaFX provides certain colors by default when rendering charts. There are situations, however, when one wants to customize these colors. In this blog post I look at changing the colors of a JavaFX pie chart using an example I intend to include in my presentation this afternoon at RMOUG Training Days 2013.

Some Java-based charting APIs provided Java methods to set colors. JavaFX, born in the days of HTML5 prevalence, instead uses Cascading Style Sheets (CSS) to allow developers to adjust colors, symbols, placement, alignment and other stylistic issues used in their charts. I demonstrate using CSS to change colors here.

In this post, I will look at two code samples demonstrating simple JavaFX applications that render pie charts based on data from Oracle's sample 'hr' schema. The first example does not specify colors and so uses JavaFX's default colors for pie slices and for the legend background. That example is shown next.

EmployeesPerDepartmentPieChart (Default JavaFX Styling)
package rmoug.td2013.dustin.examples;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.chart.PieChart;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
 * Simple JavaFX application that generates a JavaFX-based Pie Chart representing
 * the number of employees per department.
 * 
 * @author Dustin
 */
public class EmployeesPerDepartmentPieChart extends Application
{
   final DbAccess databaseAccess = DbAccess.newInstance();

   @Override
   public void start(final Stage stage) throws Exception
   {
      final PieChart pieChart =
         new PieChart(
            ChartMaker.createPieChartDataForNumberEmployeesPerDepartment(
               this.databaseAccess.getNumberOfEmployeesPerDepartmentName()));
      pieChart.setTitle("Number of Employees per Department");
      stage.setTitle("Employees Per Department");
      final StackPane root = new StackPane();
      root.getChildren().add(pieChart);
      final Scene scene = new Scene(root, 800 ,500);
      stage.setScene(scene);
      stage.show();
   }

   public static void main(final String[] arguments)
   {
      launch(arguments);
   }
}

When the above simple application is executed, the output shown in the next screen snapshot appears.

I am now going to adapt the above example to use a custom "theme" of blue-inspired pie slices with a brown background on the legend. Only one line is needed in the Java code to include the CSS file that has the stylistic specifics for the chart. In this case, I added several more lines to catch and print out any exception that might occur while trying to load the CSS file. With this approach, any problems loading the CSS file will lead simply to output to standard error stating the problem and the application will run with its normal default colors.

EmployeesPerDepartmentPieChartWithCssStyling (Customized CSS Styling)
package rmoug.td2013.dustin.examples;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.chart.PieChart;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
 * Simple JavaFX application that generates a JavaFX-based Pie Chart representing
 * the number of employees per department and using style based on that provided
 * in CSS stylesheet chart.css.
 * 
 * @author Dustin
 */
public class EmployeesPerDepartmentPieChartWithCssStyling extends Application
{
   final DbAccess databaseAccess = DbAccess.newInstance();

   @Override
   public void start(final Stage stage) throws Exception
   {
      final PieChart pieChart =
         new PieChart(
            ChartMaker.createPieChartDataForNumberEmployeesPerDepartment(
               this.databaseAccess.getNumberOfEmployeesPerDepartmentName()));
      pieChart.setTitle("Number of Employees per Department");
      stage.setTitle("Employees Per Department");
      final StackPane root = new StackPane();
      root.getChildren().add(pieChart);
      final Scene scene = new Scene(root, 800 ,500);
      try
      {
         scene.getStylesheets().add("chart.css");
      }
      catch (Exception ex)
      {
         System.err.println("Cannot acquire stylesheet: " + ex.toString());
      }
      stage.setScene(scene);
      stage.show();
   }

   public static void main(final String[] arguments)
   {
      launch(arguments);
   }
}

The chart.css file is shown next:

chart.css
/*
   Find more details on JavaFX supported named colors at
   http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html#typecolor
*/

/* Colors of JavaFX pie chart slices. */
.data0.chart-pie { -fx-pie-color: turquoise; }
.data1.chart-pie { -fx-pie-color: aquamarine; }
.data2.chart-pie { -fx-pie-color: cornflowerblue; }
.data3.chart-pie { -fx-pie-color: blue; }
.data4.chart-pie { -fx-pie-color: cadetblue; }
.data5.chart-pie { -fx-pie-color: navy; }
.data6.chart-pie { -fx-pie-color: deepskyblue; }
.data7.chart-pie { -fx-pie-color: cyan; }
.data8.chart-pie { -fx-pie-color: steelblue; }
.data9.chart-pie { -fx-pie-color: teal; }
.data10.chart-pie { -fx-pie-color: royalblue; }
.data11.chart-pie { -fx-pie-color: dodgerblue; }

/* Pie Chart legend background color and stroke. */
.chart-legend { -fx-background-color: sienna; }

Running this CSS-styled example leads to output as shown in the next screen snapshot. The slices are different shades of blue and the legend's background is "sienna." Note that while I used JavaFX "named colors," I could have also used "#0000ff" for blue, for example.

I did not show the code here for my convenience classes ChartMaker and DbAccess. The latter simply retrieves the data for the charts from the Oracle database schema via JDBC and the former converts that data into the Observable collections appropriate for the PieChart(ObservableList) constructor.

It is important to note here that, as Andres Almiray has pointed out, it is not normally appropriate to execute long-running processes from the main JavaFX UI thread (AKA JavaFX Application Thread) as I've done in this and other other blog post examples. I can get away with it in these posts because the examples are simple, the database retrieval is quick, and there is not much more to the chart rendering application than that rendering so it is difficult to observe any "hanging." In a future blog post, I intend to look at the better way of handling the database access (or any long-running action) using the JavaFX javafx.concurrent package (which is well already well described in Concurrency in JavaFX).

JavaFX allows developers to control much more than simply chart colors with CSS. Two very useful resources detailing what can be done to style JavaFX charts with CSS are the Using JavaFX Charts section Styling Charts with CSS and the JavaFX CSS Reference Guide. CSS is becoming increasingly popular as an approach to styling web and mobile applications. By supporting CSS styling in JavaFX, the same styles can easily be applied to JavaFX apps as the HTML-based applications they might coexist with.

Tuesday, February 12, 2013

JavaFX Coming Soon to an Android or iOS Device Near You?

There has been big news recently in the world of JavaFX regarding many more components of JavaFX being open sourced as advertised at JavaOne 2012. In February Open Source Update, Richard Bair compiled a table of JavaFX projects that have been open sourced as of that post's writing (Monday, 11 February 2013). As exciting as all that open sourcing is, there was something even more exciting highlighted below the table: "We’re also going to open source our iOS and Android implementations over the next couple months."

Bair adds some timing and background information to this significant announcement:

The first bits and pieces for iOS should be out next week, with the rest of iOS and Android coming out at about the same time as the rest of prism (there is some timing dependency there). Both our ports are based on an as-yet unreleased version of JavaSE Embedded for iOS/Android.

After expressing the expected caveat "I’m not a lawyer", Bair also addresses licensing issues on iOS and points out that "both OpenJFX and OpenJDK are both licensed with the same GPLv2 with Classpath Extension." He further describes his understanding of the licensing situation: "this means that if you take OpenJFX + OpenJDK (minus any binary stubs released under a different license), then you can safely combine this with your application and release your application under your own license as a single application co-bundle." I am sure we'll hear more about the licensing details in the future as this develops.

Being able to develop Android and iOS applications with JavaFX will likely be a game-changer for JavaFX. I echo Bair's concluding sentence: "I am looking forward to seeing what you all will do with this contribution, and hope to be running many Java apps on my phone / iPad in the near future." I look forward to using (and maybe even writing) some JavaFX-based apps on my Droid! I am presenting on JavaFX at Rocky Mountain Oracle Users Group (RMOUG) Training Days 2013 tomorrow, so the timing of this announcement couldn't have been better.

Monday, February 11, 2013

Hello GroovyFX

GroovyFX brings together two of my favorite things: Groovy and JavaFX. The main GroovyFX Project page describes GroovyFX as "[providing] a Groovy binding for JavaFX 2.0." GroovyFX is further described on that page:

GroovyFX is an API that makes working with JavaFX in Groovy much simpler and more natural. GroovyFX is focused on exploiting the power of the Groovy Builder pattern to make JavaFX development easier and more concise than what is possible in Java. GroovyFX also leverages Groovy's powerful DSL features and AST transformations to eliminate boilerplate, making GroovyFX code easier to write and, just as importantly, easier to read.

The just referenced main GroovyFX page includes a "Hello World" example. In this post, I look at an even simpler "Hello World" example using GroovyFX. After that, I look at a slightly more involved example of using GroovyFX to render a Pie Chart. Both of these are examples I intend to show at my RMOUG Training Days 2013 presentation ("Charting Oracle Database Data with JavaFX and Groovy") this coming week.

A bare-bones GroovyFX Hello World! example is shown in the next code listing.

import groovyx.javafx.GroovyFX
import groovyx.javafx.SceneGraphBuilder
import javafx.stage.StageStyle
import javafx.stage.Stage

GroovyFX.start
{
   stage(title: 'RMOUG Training Days 2013',
         width: 300, height: 100,
         show: true)
   {
      scene
      {
         stackPane
         {
            text('Hello GroovyFX!', x: 50, y: 40)
         }
      }
   }
}

Running the above script leads to the following output:

The code and screen snapshot show how the concise text of GroovyFX makes it easy in just a few lines of code to specify a fully functioning JavaFX graphical application.

The next code listing shows a slightly more involved examples that generates a JavaFX Pie Chart. The database access code is not shown here, but it is easily accomplished with JDBC or Groovy SQL.

import rmoug.td2013.dustin.examples.ChartMaker
import rmoug.td2013.dustin.examples.DbAccess
import groovyx.javafx.GroovyFX
import groovyx.javafx.SceneGraphBuilder
import javafx.stage.StageStyle
import javafx.stage.Stage

def databaseAccess = DbAccess.newInstance()

GroovyFX.start
{
   stage(title: 'Employees Per Department',
         width: 800, height: 500,
         show: true)
   {
      scene
      {
         stackPane
         {
            pieChart(title: 'Number of Employees per Department',
                     data: ChartMaker.createPieChartDataForNumberEmployeesPerDepartment(
                        databaseAccess.getNumberOfEmployeesPerDepartmentName()))
         }
      }
   }
}

The above GroovyFX code leads to the following screen snapshot.

The simple GroovyFX code shown above combines Groovy with JavaFX to render a pie chart representation of the number of employees per department in the Oracle 'hr' sample schema.

The next code sample indicates the roughly equivalent source code for a JavaFX application that does not use GroovyFX.

package rmoug.td2013.dustin.examples;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.chart.PieChart;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class EmployeesPerDepartmentPieChart extends Application
{
   final DbAccess databaseAccess = DbAccess.newInstance();

   @Override
   public void start(final Stage stage) throws Exception
   {
      final PieChart pieChart =
         new PieChart(
            ChartMaker.createPieChartDataForNumberEmployeesPerDepartment(
               this.databaseAccess.getNumberOfEmployeesPerDepartmentName()));
      pieChart.setTitle("Number of Employees per Department");
      stage.setTitle("Employees Per Department");
      final StackPane root = new StackPane();
      root.getChildren().add(pieChart);
      stage.setScene(new Scene(root, 800 ,500));
      stage.show();
   }

   public static void main(final String[] arguments)
   {
      launch(arguments);
   }
}

The code for the direct JavaFX example can be compared to the GroovyFX example to see how the GroovyFX syntax is more concise (as is expected for something based on Groovy) and arguably more readable than the straight JavaFX code (though I maintain the JavaFX code is fairly readable in its own right). Comparing the two code samples also helps to see how GroovyFX uses property names well-known to users of the JavaFX API.

I am a fan of Groovy and of JavaFX and GroovyFX brings them together.

Thursday, January 24, 2013

JavaFX 2 XYCharts and Java 7 Features

One of my favorite features of JavaFX 2 is the standard charts it provides in its javafx.scene.chart package. This package provides several different types of charts out-of-the-box. All but one of these (the PieChart) are "2 axis charts" (specific implementations of the XYChart). In this post, I look at the commonality between these specializations of XYChart. Along the way, I look at several Java 7 features that come in handy.

A UML class diagram for key chart types in the javafx.scene.chart package is shown next. Note that AreaChart, StackedAreaChart, BarChart, StackedBarChart, BubbleChart, LineChart, and ScatterChart all extend XYChart.

As the UML diagram above (generated using JDeveloper) indicates, the PieChart extends Chart directly while all the other chart types extend XYChart. Because all the chart types other than PieChart extend XYChart, they share some common features. For example, they are all 2-axis charts with a horizontal ("x") axis and a vertical ("y") axis. They generally allow data to be specified in the same format (data structure) for all the XY charts. The remainder of this post demonstrates being able to use the same data for most of the XYCharts.

The primary use of a chart is to show data, so the next code listing indicates retrieving of data from the 'hr' sample schema in an Oracle database. Note that JDBC_URL, USERNAME, PASSWORD, and AVG_SALARIES_PER_DEPARTMENT_QUERY are constant Strings used in the JDBC connection and for the query.

getAverageDepartmentsSalaries()
/**
 * Provide average salary per department name.
 * 
 * @return Map of department names to average salary per department.
 */
public Map<String, Double> getAverageDepartmentsSalaries()
{
   final Map<String, Double> averageSalaryPerDepartment = new HashMap<>();
   try (final Connection connection = DriverManager.getConnection(JDBC_URL, USERNAME, PASSWORD);
        final Statement statement = connection.createStatement();
        final ResultSet rs = statement.executeQuery(AVG_SALARIES_PER_DEPARTMENT_QUERY))
   {
      while (rs.next())
      {
         final String departmentName = rs.getString(COLUMN_DEPARTMENT_NAME);
         final Double salaryAverage = rs.getDouble(ALIAS_AVERAGE_SALARY);
         averageSalaryPerDepartment.put(departmentName, salaryAverage);
      }
   }
   catch (SQLException sqlEx)
   {
      LOGGER.log(
         Level.SEVERE,
         "Unable to get average salaries per department - {0}", sqlEx.toString());
   }
   return averageSalaryPerDepartment;
}

The Java code snippet above uses JDBC to retrieve data for populating a Map of department name Strings to the average salary of the employees in each department. There are a couple of handy Java 7 features used in this code. A small feature is the inferred generic parameterized typing of the diamond operator used with the declaration of the local variable averageSalaryPerDepartment (line 8). This is a small granule of syntax sugar, but it does make the code more concise.

A more significant Java 7 feature is use of try-with-resources statement for the handling of the Connection, Statement, and ResultSet resources (lines 9-11). This is a much nicer way to handle the opening and closing of these resources, even in the face of exceptions, than was previously necessary when using JDBC. The Java Tutorials page on The try-with-resources Statement advertises that this statement "ensures that each resource is closed at the end of the statement" and that each resource will "be closed regardless of whether the try statement completes normally or abruptly." The page also notes that when there are multiple resources specified in the same statement as is done in the above code, "the close methods of resources are called in the opposite order of their creation."

The data retrieved from the database can be placed into the appropriate data structure to support use by most of the XYCharts. This is shown in the next method.

ChartMaker.createXyChartDataForAverageDepartmentSalary(Map)
/**
 * Create XYChart Data representing average salary per department name.
 * 
 * @param newAverageSalariesPerDepartment Map of department name (keys) to
 *    average salary for each department (values).
 * @return XYChart Data representing average salary per department.
 */
public static ObservableList<XYChart.Series<String, Double>> createXyChartDataForAverageDepartmentSalary(
   final Map<String, Double> newAverageSalariesPerDepartment)
{
   final Series<String, Double> series = new Series<>();
   series.setName("Departments");
   for (final Map.Entry<String, Double> entry : newAverageSalariesPerDepartment.entrySet())
   {
      series.getData().add(new XYChart.Data<>(entry.getKey(), entry.getValue()));
   }
   final ObservableList<XYChart.Series<String, Double>> chartData =
      FXCollections.observableArrayList();

   chartData.add(series);
   return chartData;
}

The method just shown places the retrieved data in a data structure that can be used by nearly all of the XYChart-based charts. With the retrieved data now packaged in a JavaFX observable collection, the charts can be easily generated. The next code snippet shows methods for generating several XYChart-based charts (Area, Bar, Bubble, Line, and Scatter). Note how similar they all are and how the use the same data provided by the same method. The StackedBar and StackedArea charts can also use similar data, but are not shown here because they are not interesting for the single series of data being used in this example.

Methods for Generating XYCharts Except BubbleChart and Stacked Charts
private XYChart<String, Double> generateAreaChart(
   final Axis<String> xAxis, final Axis<Double> yAxis)
{
   final AreaChart<String, Double> areaChart =
      new AreaChart<>(
         xAxis, yAxis,
         ChartMaker.createXyChartDataForAverageDepartmentSalary(
            this.databaseAccess.getAverageDepartmentsSalaries()));
   return areaChart;
}

private XYChart<String, Double> generateBarChart(
   final Axis<String> xAxis, final Axis<Double> yAxis)
{
   final BarChart<String, Double> barChart =
      new BarChart<>(
         xAxis, yAxis,
         ChartMaker.createXyChartDataForAverageDepartmentSalary(
            this.databaseAccess.getAverageDepartmentsSalaries()));
   return barChart;
}

private XYChart<Number, Number> generateBubbleChart(
   final Axis<String> xAxis, final Axis<Double> yAxis)
{
   final Axis<Number> deptIdXAxis = new NumberAxis();
   deptIdXAxis.setLabel("Department ID");
   final BubbleChart<Number, Number> bubbleChart =
      new BubbleChart(
         deptIdXAxis, yAxis,
         ChartMaker.createXyChartDataForAverageDepartmentSalaryById(
            this.databaseAccess.getAverageDepartmentsSalariesById()));
   return bubbleChart;
}

private XYChart<String, Double> generateLineChart(
        final Axis<String> xAxis, final Axis<Double> yAxis)
{
   final LineChart<String, Double> lineChart =
      new LineChart<>(
         xAxis, yAxis,
         ChartMaker.createXyChartDataForAverageDepartmentSalary(
            this.databaseAccess.getAverageDepartmentsSalaries()));
   return lineChart;
}

private XYChart<String, Double> generateScatterChart(
   final Axis<String> xAxis, final Axis<Double> yAxis)
{
   final ScatterChart<String, Double> scatterChart =
      new ScatterChart<>(
         xAxis, yAxis,
         ChartMaker.createXyChartDataForAverageDepartmentSalary(
            this.databaseAccess.getAverageDepartmentsSalaries()));
   return scatterChart;
}

These methods are so similar that I could have actually used method handles (or more traditional reflection APIs) to reflectively call the appropriate chart constructor rather than use separate methods. However, I am using these for my RMOUG Training Days 2013 presentation in February and so wanted to leave the chart-specific constructors in place to make them clearer to audience members.

One exception to the general handling of XYChart types is the handling of BubbleChart. This chart expects a numeric type for its x-axis and so the String-based (department name) x-axis data provided above will not work. A different method (not shown here) provides a query that returns average salaries by department ID (Long) rather than by department name. The slightly different generateBubbleChart method is shown next.

generateBubbleChart(Axis, Axis)
   private XYChart<Number, Number> generateBubbleChart(
      final Axis<String> xAxis, final Axis<Double> yAxis)
   {
      final Axis<Number> deptIdXAxis = new NumberAxis();
      deptIdXAxis.setLabel("Department ID");
      final BubbleChart<Number, Number> bubbleChart =
         new BubbleChart(
            deptIdXAxis, yAxis,
            ChartMaker.createXyChartDataForAverageDepartmentSalaryById(
               this.databaseAccess.getAverageDepartmentsSalariesById()));
      return bubbleChart;
   }

Code could be written to call each of these different chart generation methods directly, but this provides a good chance to use Java 7's method handles. The next code snippet shows this being done. Not only does this code demonstrate Method Handles, but it also uses Java 7's multi-catch exception handling mechanism (line 77).

/**
 * Generate JavaFX XYChart-based chart.
 * 
 * @param chartChoice Choice of chart to be generated.
 * @return JavaFX XYChart-based chart; may be null.
 * @throws IllegalArgumentException Thrown if the provided parameter is null.
 */
private XYChart<String, Double> generateChart(final ChartTypes chartChoice)
{
   XYChart<String, Double> chart = null;
   final Axis<String> xAxis = new CategoryAxis();
   xAxis.setLabel("Department Name");
   final Axis<? extends Number> yAxis = new NumberAxis();
   yAxis.setLabel("Average Salary");
   if (chartChoice == null)
   {
      throw new IllegalArgumentException(
         "Provided chart type was null; chart type must be specified.");
   }
   else if (!chartChoice.isXyChart())
   {
      LOGGER.log(
         Level.INFO,
         "Chart Choice {0} {1} an XYChart.",
         new Object[]{chartChoice.name(), chartChoice.isXyChart() ? "IS" : "is NOT"});
   }

   final MethodHandle methodHandle = buildAppropriateMethodHandle(chartChoice);
   try
   {
      chart =
        methodHandle != null
      ? (XYChart<String, Double>) methodHandle.invokeExact(this, xAxis, yAxis)
      : null;
      chart.setTitle("Average Department Salaries");
   }
   catch (WrongMethodTypeException wmtEx)
   {
      LOGGER.log(
         Level.SEVERE,
         "Unable to invoke method because it is wrong type - {0}",
         wmtEx.toString());
   }
   catch (Throwable throwable)
   {
      LOGGER.log(
         Level.SEVERE,
         "Underlying method threw a Throwable - {0}",
         throwable.toString());
   }

   return chart;
}

/**
 * Build a MethodHandle for calling the appropriate chart generation method
 * based on the provided ChartTypes choice of chart.
 * 
 * @param chartChoice ChartTypes instance indicating which type of chart
 *    is to be generated so that an appropriately named method can be invoked
 *    for generation of that chart.
 * @return MethodHandle for invoking chart generation.
 */
private MethodHandle buildAppropriateMethodHandle(final ChartTypes chartChoice)
{
   MethodHandle methodHandle = null;
   final MethodType methodDescription =
      MethodType.methodType(XYChart.class, Axis.class, Axis.class);
   final String methodName = "generate" + chartChoice.getChartTypeName() + "Chart";

   try
   {
      methodHandle =
         MethodHandles.lookup().findVirtual(
            this.getClass(), methodName, methodDescription);
   }
   catch (NoSuchMethodException | IllegalAccessException exception)
   {
      LOGGER.log(
         Level.SEVERE,
         "Unable to acquire MethodHandle to method {0} - {1}",
         new Object[]{methodName, exception.toString()});
   }
   return methodHandle;
}

A series of images follows that shows how these XY Charts appear when rendered by JavaFX.

Area Chart
Bar Chart
Bubble Chart
Line Chart
Scatter Chart

As stated above, Method Handles could have been used to reduce the code even further because individual methods for generating each XYChart are not absolutely necessary and could have been reflectively called based on desired chart type. It's also worth emphasizing that if the x-axis data had been numeric, the code would be the same (and could be reflectively called) for all XYChart types including the Bubble Chart.

JavaFX makes it easy to generate attractive charts representing provided data. Java 7 features make this even easier by making code more concise and more expressive and allowing for easy application of reflection when appropriate.

Thursday, October 4, 2012

JavaOne 2012: Mastering Java Deployment

After grabbing an Italian Classic Combo for another JavaOne 2012 lunch, I headed to Hilton Imperial Ballroom B to see the presentation "Mastering Java Deployment." The speakers, both from Oracle, were Mark Howe and Igor Nekrestyanov.

Howe stated that a goal of the deployment team is to help Java developers deploy their applications to platforms of choice. He started by discussing "feature deprecation." In some cases, there are multiple ways to do the same thing. An example of this is jarjar and pack200. By deprecating redundant (especially older) approaches, they don't have to spend as much time supporting and fixing bugs on these seldom used things.

Howe showed a table of features being deprecated and removed in JDK 7, JDK 8, and JDK 9. In general, anything being deprecated and/or removed has alternatives and folks using the deprecated/removed features should start looking at which alternative works best for them.

As of JRE 7 Update 6, a totally Oracle-supported JRE will be issued for Mac OS X. Oracle's intention is to fix bugs and add features across JVMs for all deployment environments at the same time. The JRE 7 is "mostly compatible" with Apple's JRE 6. One change is to be more aligned with Oracle's JVM support for other platforms and have Oracle's updated update the JRE on Mac OS X rather than using the Mac "Software Update." One caveat is that "Chrome on Mac is currently unsupported (32-bit only)."

In continuing the theme of platform JVM feature polarity, JavaFX is now delivered with JRE for Linux. Howe's "Convergence of Java and JavaFX" slide showed a table indicating the progress of converging Java and JavaFX versions. The goal is for JavaFX to be one of the core libraries in the Java specification. Plans for JDK 8 include "Java launcher able to run JavaFX applications" and "jfxrt.jar on boot classpath for java and javac."

Howe introduced the Java Deployment Toolkit and described it as a "tool to simplify deployment of Java content in the browser." He contrasted deployJava.js ("original version") with dtjava.js ("better JavaFX support and portability"). The dtjava.js version "supports all deployment scenarios on all platforms" though there is no autostart on Mac or Linux.

Howe talked about WebStart and explained that "user experience is not quite as nice as you'd like it to be." He contrasted this with use of dtjava.js that allows developer to set parameters for control of launching from JavaScript. It makes for more control and better user experience. This also removes need for fixed code base. The code shown in a slide for using dtjava.launch requires JRE 7 Update 6 or later.

The goal of packaging tools is to "simplify deployment for application developers." The command-line tool bin/javfxpackager (or set of Ant tasks lib/ant-javafx.jar) can be used with JDK 7 Update 6. The "latest release of NetBeans" supports these.

Howe covered several motivations for completely self-contained applications. A self-contained applications contains "all the artifacts necessary to run your application." It has a private copy of the Java runtime and removes the dependency on the external JRE. Many of the motivations for self-contained applications revolved around issues of acquiring a current JRE to run the application.

Benefits of self-contained applications include the feeling of a native application, improved compatibility, easier deployment on a fresh system, optional administrative privileges, and support of newer distribution channels such as the Apple Apps Store. The caveats of self-contained applications include larger size (JRE included), "download and run" instead of WebStart's "click and launch," need to build package per platform, and other current limitations such as package needing to be built on the target platform and application updates being the responsibility of the developer."

To create a self-contained application, one needs JDK 7 Update 6 as well as optional third party tools such as WiX to build MSI on Windows. Howe showed a slide with Ant code for generating the self-contained application. The Developer Preview will allow a developer to select target version of JVM (current choices are JRE 7 Update 6 or JRE Update 10). The Developer Preview is expected to be available with JRE 7 Update 10. JDK 7 Update 10 is also anticipated to support Mac App Store support.

Like so many other presentations at JavaOne 2012, community feedback was solicited. In this case, the deployment team would like to know what people want and need for more effective web deployment of Java applications. Howe had a nice slide comparing executable JAR to WebStart to self-contained application.

Mac App Store does not allow applications to "rely on optionally-installed technology." Other requirements include need for application to "run in a sandbox" and "follow UI guidelines." Certain APIs (FileChooser) should be avoided. See JavaOne 2012 slides for "Deploy Your Application with OpenJDK 7 on Mac OS X" and future version of JavaFX Deployment Guide for more details.

Howe's "key points to remember" include merging of Java with JavaFX, new platforms for Java, new deployment options (self-contained application bundle and deployment to Mac App Store), and deprecation of old deployment features.

One of the attendees asked if there is a way to share a single JRE among multiple shared self-contained applications. The answer is that there currently is not a way to do this, but that a JRE can optionally not be included in the otherwise self-contained application.

In responses to another question, the speakers stated they are not aware of any plans to deprecate Swing. They also responded to yet another question that there is currently no Maven support for building self-contained applications (use Ant or NetBeans).

There were several good slides shown in this presentation that I'd like to look at more closely in the future. Fortunately, Howe stated that these will be made available. Much of what was covered in this session will be open source and audience members were encouraged to contribute to the open source projects.

Wednesday, October 3, 2012

JavaOne 2012: JavaFX Graphics Tips and Tricks

I returned to the Hilton (Imperial Ballroom B) to see Richard Bair's (Oracle Java Client Architect) "JavaFX Graphics Tips and Tricks." Bair is associated with FX Experience and obviously knows JavaFX.

Bair said a theme of his talk is on performance. He cautioned that as with most things performance related, avoid performance pre-optimization. He had a big yellow caution screen stating "WRITE CLEAN CODE, THEN PROFILE!" He said his talk is based on JavaFX 2.2 and some of the tips and tricks may not be applicable with JavaFX 8.

Bair covered the "GUIMark 2 Vector" benchmark for several browers on three different operating systems (versions not specified): Windows, Linux, and Mac OS X. Bair compared JavaFX to these browsers' native support. He also pointed out that sometimes SceneGraph is faster and sometimes Canvas is faster. Many of the points Bair brought up are more important on smaller devices than on desktops.

JavaFX was much quicker than the browsers in GUIMark 2 Bitmap and JavaFX Canvas was the quickest of all. The GUIMark 2 Text test did not provide useful data for Windows due to limited rate, but JavaFX did well on Linux and Mac OS X. Bair intends to release benchmarking approaches for public consumption and he showed a chart indicating significant performance improvement from JavaFX 2.2 to JavaFX 8.

Bair's Performance Rule #1 is "Do Less Work." Bair stated, "Smaller systems require a much more intense round of performance tuning." He added that "every line counts" and "extra method calls add up." Although in traditional desktop Java we've been taught not to worry about number of methods calls, this can be an issue on smaller devices ("excessive inlining is expensive" and "excessive method invocations are expensive"). Bair showed how to use a local final variable to reduce the number of method invocations. He acknowledged that it is "absolutely micro performance pre-optimization" on the desktop, but is a useful tactic for smaller devices.

Bair said that "fill rate" is a limitation with "nearly 100% certainty." Geometry rate is unlikely to be a significant limit in JavaFX unless you have "zillions of vertices." CSS overhead is a possible limitation as is layout computation. JavaFX does a lot of caching and the latter may not always be an issue. There is a "good chance" that system I/O will limit you, especially on smaller devices.

Bair showed an example of "abusing the fill rate" by drawing the furthest back background first and then drawing over the majority of that with another fill. He had some points for avoiding this unnecessary filling such as "only draw what has changed." Bair pointed out that the developer identifies "dirty regions" in Swing, but that JavaFX SceneGraph "does this automatically!" He did caution that JavaFX Canvas requires the developer to identify the "dirty regions."

Another approach for improving fill rate is to "limit use of (some) effects." "Effects are almost free on your desktop systems," but may need to watch them more closely on smaller devices. Bair discussed a bullet stating, "Limit use of non-rectangular non-axis aligned clips" as another tactic for improving fill rate. Directly clipping aligned images is quick, but the process of anti-aliasing, rendering as a background image, and rotating non-aligned pixel boundaries "costs you a little more" (but you won't notice on most desktop applications).

Bair stated that reducing overdraw is an effective way of improving fill rate. Related to reduction of overdraw, he discussed using "image skinning." Bair also mentioned here that JavaFX 8 includes automatic region texture cache. Other ideas for reducing overdraw include simplifying the style (Metro, Android), consolidating background fills, and reducing the number of overlapping nodes.

Bair stated that Microsoft intentionally came up with an easy-to-draw style in Metro. The Android style is similarly quicker and easier to draw.

"Occlusion Culling" allows avoidance of drawing (culling) things that won't be visible." Doing this allows us to "reduce overdraw and increase rendering performance." The JavaFX engine can respond to JavaFX CSS opaque insets to know when to not redraw these areas.

There are CSS costs to be aware of such as parsing a stylesheet. Bair showed a "CSS Horror Show" slide with .parent:hover .child {...} and explanation of why this is so terrifying: all the children must be revisited each time the parent is hovered over. Similarly, .parent .child {...} can be bad if there is a large number of children since "when we encounter a node with the .child style class, we must walk up the entire scene graph until we find it." It is better to limit the search to immediate parent.

Bair stated that the setStyle CSS property is very convenient, but can be costly. The parsing and other support can add to performance problems. CSS provides power, flexibility, and convenience, but that does come at a performance cost.

One of Bair's tips is to "avoid structural changes to SceneGraph." All CSS from the changed point on down must be recomputed. Besides this reapplication of CSS, "structural integrity checks" are required when the SceneGraph is changed. JavaFX has optimized toFront/toBack, so use these rather than removing and adding back.

Another Bair tip is to "use FXCollections." His first bullet on this stated, "Shoot for minimal notification overhead." A sub-bullet recommended using setAll instead of clear and addAll. Another sub-bullet added, "Avoid multiple add calls."

Use of FXColections.sort() is best because it "sends 'permutation' change events." This means that JavaFX engine knows what has changed and so only recomputes what is necessary for that specific type of change. These "permutations" are "handled by separate fast paths."

Bair stated that "ListView is blistering fast" because it "reuses nodes" and maintains minimum changes. Bair concluded that slide with "Reuse ListView for all your virtualization needs!"

Bair's "Manual Layout" tip included the idea of custom extensions of Region. He cautioned that you almost always need to implement computePrefWidth and computePrefHeight when extending Region.

Bair had a slide listing the questions that "JavaFX asks" when handling layout. These are questions like "How wide/tall would you like to be?" and "Can you be resized?" JavaFX asks these questions at least once and sometimes many more times that number of times when trying to render a layout. A customized layout can reduce the number of times attempted and the number of questions asked. "JavaFX asks a lot of questions" and they are "all asked for each node during layout."

Bair had a "Major Tip!" related to "Content Bias." If height depends on width, you're HORIZONTAL biased. If width depends on height, you're VERTICAL biased. Bair stated that "(contentBias = null) is by far the fastest" (all computed preferences for height and width are cached). Content Bias is typically null or horizontal. There is a bug in that "contentBias != null isn't actually well supported in the built-in layouts."

Everything covered so far has been under Bair's Rule #1 (do less work). Rule #2 is now "Know Your Device." Bair showed a slide comparing the powerful NVidia GForce GTX 690 to the less powerful NVidia GForce 310 and to the even lowlier PowerVR SGX543MP3. Bair's point, of course, is that "JavaFX gives you a single development platform and a single set of APIs, but which APIs you can and can't use is going to depend on the inherent performance characteristics of the device."

Bair had some rules of thumb for JavaFX on devices. Use desktop application for handling 20 thousand to 100 thousand nodes. Five hundred to one thousand nodes is the better range for embedded. For really small embedded devices, stick to range of 100 to 200 nodes for the JavaFX application.

Bair provided another tip related to cache. He talked about caching a chart because it will then only be drawn to the image once and can then quickly be drawn to the screen "a bazillion times." Bair cautioned, though, that this "backfires if the node is changing a lot." Bair said that he'll often turn cache to true, do an animation, and then set cache to false again.

CacheHint can be set to SPEED when rotating and scaling for better performance. If you want it redrawn when it rotates for greater accuracy, then use cache hint other than SPEED.

JavaFX 8 has a Pulse Logger (-Djavafx.pulseLogger=true system property) that "prints out a lot of crap" (in a good way) about the JavaFX engine's execution. There is a lot of provided information on a per-pulse basis including pulse number (auto-incremented integer), pulse duration, and time since last pulse. The information also includes thread details and events details. This data allows a developer to see what it taking most of the time.

Bair ended the session with the same bright yellow caution slide: Write Clean Code, Then Profile! The slide also points out, "Don't overdo it or you will have an unmaintainable mess."

Tuesday, October 2, 2012

JavaOne 2012: JavaFX on Smart Embedded Devices

My first trip to Hotel Nikko for JavaOne 2012 came on Tuesday afternoon when I ventured to Nikko Ballroom II/III for David Hill's "JavaFX on Smart Embedded Devices." This was my second during-conference change in sessions. I had planned originally to attend the always-excellent Mark Reinhold talk on "The Modular Java Platform and Project Jigsaw," but just could not muster the motivation to attend a presentation, even from Reinhold, on a subject that won't be more directly relevant until at least 2015. I hope to catch him talking on Project Jigsaw at a conference in 2014.

With around 30 to 35 people in the audience at session start time, this was probably the least crowded session I've attended so far (the room would hold many times that number of people). It seems that the sessions starting at 3 pm after the only one-hour break of the day take a hit in terms of attendees who come at all and who come on time. The fact that this presentation was also in the Nikko and the festivities are now on the other (Taylor Street) side of the Hilton (used to be on the Mason Street side) may also have played a role. Or, it could be explained by the intersection of embedded developers and JavaFX developers being a small sample.

Hill started with a few questions. Less than half of the audience considers themselves to be embedded developers, but the vast majority have some degree of familiarity with JavaFX. Hill had a "JavaFX" slide that listed four bullets introducing JavaFX and he emphasized that JavaFX Embedded targets GPUs.

Hill quickly moved on from his introduction to JavaFX given the familiarity in the room with JavaFX. His slide "JavaFX Embedded" talked about potential markets: industrial automation, home automation, home entertainment systems, medical devices, automotive, and retail/informational kiosks.

Hill defined JavaFX Embedded as "a proper subset of JavaFX" without dependency on AWT or Swing. The later point implies that JavaFX Embedded cannot be used with the wrappers for Swing and SWT. He added that NetBeans and Scene Builder are tools common to both JavaFX and to JavaFX Embedded.

Hill talked about JavaFX Embedded rendering as well as input via mouse and keyboard and touch screens. JavaFX Embedded supports a virtual touch keyboard.

JavaFX Embedded's minimum footprint goal is approximately 16 MB (10 MB from Java Embedded SE and 6 MB from JavaFX Core). Media, Charts, and WebView (future release) will require the cost of additional memory footprint.

JavaFX Embedded has a "porting layer" on top of the mostly common code with the desktop. The porting layer is small and includes a Window Manager, special input, rendering, media decoders, and Webnode (future).

One of Hill's slides emphasized JavaFX features that won't be in JavaFX Embedded 8: System Menu support, Swing/SWT related nodes, drag and drop, and WebView. Only the last (WebView) "may make sense" for JavaFX Embedded.

JavaFX Embedded Developer Preview for ARM was made available on the same day as the JavaOne 2012 Strategy and Technical Keynotes. The targeted platforms are Linux 3.x and ARM. One of the challenges was picking the target platforms for limited resources to be focused on. Some of the "monitored platforms" include Raspberry Pi, Freescale I.MX53, and PandaBoard.

The JavaFX Embedded team is looking at several rendering paths. They currently prefer OpenGL ES2, EGL, and Frame Buffer. Hill talked about using DirectFB to Frame Builder without AWT dependency as another potential rendering path. Using OpenGL ES2, EGL, and X11 is yet another potential rendering path, but it adds overhead and limitations as well and won't be part of Java SE Embedded 8 release.

JavaFX Embedded uses GStreamer and they plan to support vendor-supplied GStreamer plugins.

Hill said that a desktop JavaFX application "probably will" run on an embedded device, but likely won't be usable. Real estate concerns are just one of several that arise when moving from desktop to embedded device. He reminded the audience that embedded platforms tend to have "slower CPU/GPU," "less memory," "likely smaller display" (Raspberry Pi outputs in high definition), and possibly a touch screen. He said you'll more likely be able to run your JavaFX Embedded application on a desktop.

Design considerations for JavaFX Embedded applications include maintaining simplicity when possible. Complex scene graphs will slow rendering. It is important to "free up unused resources," but this is a trade-off of memory for time. JavaFX has numerous effects and their performance costs differ based on the platform GPU. Another design consideration is to load pre-scaled images to avoid wasting "precious memory" to load a large image.

The minimum set of resources to run a JavaFX Embedded application include Linux, the JVM, and accelerated graphics. The question prompting this was related specifically to Raspberry Pi and Hill believes that environment is satisfactory for JavaFX Embedded.

This session interested me even though I don't have any familiarity with embedded development. I like to attend several sessions with practical and actionable things for me to learn, but I like to attend a few presentations like this that expand my view beyond my comfort zone.

Monday, June 4, 2012

Recent Software Development Posts of Interest - Early June 2012

There has recently been a large number of posts on some of my favorite topics and I summarize and reference a few of them here.

Why Developers Should Blog

I devoted a post to why I believe more software developers should write blogs. Ron Gross's post Why you should write a blog post today provides five reasons to write technical blog posts and contrasts blogs to other social media to demonstrate technical memento advantages of blogs.

NetBeans 7.2 Search Capability

There has been significant coverage of NetBeans 7.2 beta in recent weeks. Much of the focus has been on its improved performance, its greater helpfulness and its TestNG support. Geertjan Wielenga focuses on improved searching capability in NetBeans 7.2 beta in his post Beefed Up Code Navigation Tools in NetBeans IDE 7.2.

Running Common Java Development Tools with Ant

Modern Java IDEs often make it easy to integrate Java tools. An example is the NetBeans SQE plugin. However, not all Java development and execution necessarily occurs in the IDE. In addition, some projects may use more than one IDE. In such cases, command-line approaches have their advantages. These can be even easier to use when run as Ant targets. The post How to run Findbugs, Pmd, Checkstyle, JUnit and Cobertrua with an Ant Build-Script? covers using Ant to run popular Java development tools FindBugs, PMD, Checkstyle, JUnit, and Cobertura.

Upgrading Gradle

I think that Gradle has a lot of potential for being a very popular build tool if it can gain enough early traction. The post Upgrading Gradle demonstrates how easy it is to upgrade one's Gradle installation ("It’s basically the same as upgrading ant.").

SVG, FXML, and NetBeans

The post SVG to FXML using NetBeans comprehensively covers issues related to transforming SVG to FXML and ends with a link to another post showing how to use NetBeans to demonstrate the transformation.

Conclusion

There have been numerous posts in recent weeks on some of my favorite topics: NetBeans, blogging, Gradle, and JavaFX. This post has referenced a sample of these posts.

Monday, May 28, 2012

NetBeans 7.2 beta: Faster and More Helpful

There has been significant excitement about the beta release of NetBeans 7.2. In this post, I look briefly at what makes this release so exciting (including better performance, providing more hints, and integrating FindBugs).

NetBeans 7.2 beta is available in the typical download bundles, ranging from the smaller Java SE, C/C++, and PHP bundles to the larger Java EE and "All" bundles. Installation of NetBeans 7.2 is as easy as ever and there are installation instructions for multiple platforms.

Speed!

The NetBeans IDE 7.2 Beta Release Notes include a section called What's New in 7.2 Beta which states of NetBeans 7.2, "Significant performance increase on remote filesystems, improved project scanning speed, and background project scanning." As I discussed in my recent post NetBeans Usability Tips, larger projects or numerous associated projects can lead to significant NetBeans performance degradation. In that post, I looked at how one can turn off that background source scanning to avoid this when necessary. The NetBeans development team has apparently heard many others wish for quicker scanning and they have focused on this and quicker startup for NetBeans 7.2 beta

The NetBeans 72 NewAndNoteworthy page provides additional information on the quicker performance. It states, "The indexes and indexing infrastructure were rewritten to use transactions. The project scanning and up to date check do not block editor features nor navigation. These features use the previous committed index. Also the write transactions are suspended by read transactions, so the background indexing has lower priority than user actions." That same page also states, "The binary indexers run in parallel which makes indexing of java project faster."

New NetBeans Hints

I like NetBeans's hints so much that I have written multiple posts about them: Seven Indispensable NetBeans Java Hints, Seven NetBeans Hints for Modernizing Java Code, and Creating a NetBeans 7.1 Custom Hint. NetBeans 7.2 adds several new hints including "Generate Implementing/Extending Class," "Zero Element Array Passed to Collection.toArray," "Method Result not Checked" (uses the FindBugs annotation @CheckReturnValue), "Generate switch Clauses," and "Fix Missing return Statement."

One of the new hints added in NetBeans 7.2 would have fit nicely in my post Seven NetBeans Hints for Modernizing Java Code. The "Add Underscores to Integer Literals" hint can help "modernize" Java code bases to leverage this new Java 7 feature.

The following screen snapshots demonstrate the utility of the new NetBeans 7.2 hint for including underscores in integer literals to improve readability. As the first screen snapshot indicates, there is some configuration available related to this hint. Also note that in my case of upgrading from NetBeans 7.1.1 to NetBeans 7.2 beta, this hint was not enabled (not checked) in the Tools | Options | Editor | Hint area.

FindBugs Integration

NetBeans 7.2 beta integrates FindBugs into the IDE. This makes it even easier and more intuitive to apply FindBugs to Java code in NetBeans than use of the Software Quality Environment I discussed in the post NetBeans 7 and Software Quality Environment.

The FindBugs Integration Plugin can be installed on NetBeans 7.2 beta using the Tools | Plugins | Available Plugins approach shown in the next screen snapshot.

An alternative approach for acquiring and installing the FindBugs Integration Plugin is through the source code inspection process. This can be done by selecting Source | Inspect (shown in next two images).

Note that FindBugs Integration is one of the items that can be explicitly selected, but I prefer to use "All Analzyers." Click on the "Install" button to see what "additional plugins [are] required for the selected configuration." In the case of the newly installed NetBeans 7.2 beta, the following appeared when I clicked on that "Install" button.

Once FindBugs Integration 1.8 plugin is installed, NetBeans begins reported FindBugs findings.

As noted in this post's section on the new NetBeans hints, the FindBugs annotation @CheckReturnValue is also now supported by a NetBeans hint.

JavaFX SceneBuilder Support

The SceneBuilder tool is an IDE-independent standalone tool announced at JavaOne 2011 for generating JavaFX interfaces that was released to the public earlier this year. As Cindy Castillo states in the post JavaFX Scene Builder Docs Updated, the Getting Started with JavaFX Scene Builder documentation now discusses (in fact, requires) use of NetBeans 7.2 beta for the tutorial. The SceneBuilder is still a separate tool, but it can be opened from NetBeans by simply clicking on an FXML file. The clicked-on FXML file will be loaded in the SceneBuilder instance that is started.

Miscellaneous Improvements

NetBeans 7.2 beta includes several other improvement including supporting and bundling of Ant 1.8.3, bundling Maven 3.0.4, C++11 support, support for Java 7 Update 4, and support for Oracle Cloud. The NetBeans 7.2 integration of TestNG is also interesting.

Conclusion

There's a lot to like about NetBeans 7.2, even in its beta release. It is faster and more helpful than its direct predecessors and integrates with many of the most popular Java and software tools and frameworks available today. The NetBeans 7.2 beta fanfare even attracted a self-proclaimed Eclipse user to try it out. There is substance behind the fanfare in this case. As Chris Mayer has stated regarding NetBeans 7.2 beta, "The most inclusive IDE just got a little bit sweeter."