JFX Blocks Plugin 0.2 For NB Released

JFX Blocks Plugin 0.2 for NetBeans has been released on Kenai. Here is the list of features for this plugin:

• Create Test Case for a JavaFX source file (found in file's popup menu)
  
• Create Model Validator for a JavaFX source file (found in file's popup menu)
• Wizards for creating custom Lookups, App Controllers, Blocks, and Test Runners (for running Unit Tests)

With the "Create Model Validator" option it only creates the basic class structure for a Model Validator. It is planned to have default validation for model fields generated in the custom Model Validator in the next plugin release. As for an option to run the Unit Tests through a Test Runner, this may also be in the plan for the next release.

JavaFX App Development Part 1

Currently I am developing a JavaFX application for handling cooking recipes called Cookery. Part 1 will cover my development experiences using the JavaFX Composer in NB 6.9 RC1. Previously I had written Cookery entirely using the NB code editor and JavaFX 1.2. Unfortunately I had encountered some show stopper performance issues (with data binding) during testing, which meant I could not make any further progress with the application. This time around Cookery is undergoing a complete rewrite from scratch using JavaFX 1.3.

Since I had developed Cookery previously I had some rough screen designs on paper. Using the Composer I was able to design screens that were close to what I had on paper. Unfortunately the Composer does not yet support custom controls/classes/nodes, which meant containers had to be used during layout to hold the custom controls, thus no accurate visual feedback. On the plus side I was able to setup the layout for each screen quickly and easily.

The Composer organises control properties in a sensible way that is easily accessible. I like that fact that all commonly used properties for the selected control is presented in the top area of the Properties window. Not all properties are available in the Properties window, of particular mention is the read only properties which do not appear at all. Strangely enough there is still to way to visually manipulate the properties for the Stage (eg set the title), and properties are not sorted in ascending order for each category.

If you have ever used the previous version of the Composer you will no doubt have run into some major performance issues. Luckily with the current version it is much more responsive, and opens up design files much quicker. Also whenever a small change is made to a design file and you rerun the JavaFX project it is much quicker to build, this helped to boost productivity when the project was being built many times.

A major downside with using the Composer is the fact that it does not honour the user's formatting settings when it generates code. This slowed development down unnecessarily while I had to fix up the formatting. One major issue that is of major concern is the excessive amount of scanning that occurs whenever a change is made to a design file. This verges close to being a performance show stopper. Hopefully this issue is becoming priority number 1 with the Composer team, and will be fixed by the time the final version of NB 6.9 arrives. If necessary NB 6.9 should be delayed by about a week. It appears that the scanning issue is very common in other areas (eg JavaFX, PHP, Java).

On the positive side using the menu bar customiser proved to be a highly productive experience. Initially when I first used it I though it would not be as productive to use as Matisse's one (NB's Swing GUI builder). Who wants to manually type out the menu structure? However it proved to be the direct opposite, even saving me from manually renaming/positioning all menus/menu items. Also each menu can be customised individually without having to create the menu from scratch.

Another positive with using the Composer is that is generates very readable code that happens to be in a coding style that is very similar to my own. Any generated event handlers and binding functions/variables can be manually repositioned/changed on the fly. For handling data/state there is the Composer library which came in handy since I needed a general JavaFX database library for the application. There were two issues with the library which I was able to fix since all the source files are automatically created (for the first time only) in the project's src directory.

Listed below are the issues I encountered with the Composer and its library (most issues have workarounds):


Getting a value from a Record returns null

Ensure that the column name is correct and is in the correct case (eg in upper case).


Composer does not allow a custom control to be used visually in the Design Pane

Use a place holder Container (eg Group) in the control's place, and manually add the control to the Container.


Cannot directly resize Container's in the Design Pane

No workaround.


Cannot set any of the properties for the Stage (eg the title) in the Properties window

No workaround.


JDBC Data Source customiser does not handle a custom connection string

Change the connection property in the Properties window for the data source.


Sometimes the design file cannot be manually saved when a change is made

Close the design file and select the Save option when the dialog appears.


Excessive scrolling needs to be done with a design file in Design mode

No workaround.


Refactoring breaks when done in a design file (in Source mode)

Do manual refactoring without the assistance of the code editor's refactoring functions.


JavaFX Script code generated the Composer does not honour the user's formatting settings

Manually format the generated code.


DbDataSource returns a null RecordSet via getRecordSet function

Ensure all DbDataSource properties are correct. Also you may need to invoke the fetchData function before getting the RecordSet.


RecordSet returns null when using get(colName) function on a table column of type CLOB

Manually add code in the fetchData function (in DbDataSource) for retrieving CLOBs.


DbDataSource does not return the last insert ID used

Manually add code in DbDataSource to get the last insert id. Only a workaround if the chosen DB has a function that returns the last insert ID.


RecordSet does not have a specific function for retrieving a xxx type value from a column

Use the get function instead to retrieve the value and cast it to the specific type

JavaFX Composer Overview

With the release of JavaFX Composer (the JavaFX GUI builder for NetBeans) I decided to go through a general overview of the tool. With the overview it will answer some key questions which include identifying any missing areas not covered by the tool, point out any of the tool's strengths, point out any of the tool's weaknesses, and look at the major differences between Masisse (the Swing GUI builder for NetBeans) and JavaFX Composer.



Key Questions

Before the release of JavaFX Composer there were some key questions compiled about the tool that needed answers. These questions are:

• Can data binding be done visually?
• Does JavaFX Composer handle creating/editing animations visually?
• Are GUI changes reflected in real time as they occur?
• Is the .fxc file format also used in the JavaFX Authoring tool (for exchanging view data)?
• Can custom JavaFX controls be added to the palette via drag 'n' drop or through a wizard?
• Does JavaFX Composer support visual binding of data to/from a DB?
• What differences are there between JavaFX Composer and the JavaFX Authoring tool?
• What are “states” in JavaFX Composer?
• What advantages will JavaFX Composer have over Matisse?
• What is the relationship between JavaFX Composer and JavaFX Designer?

Differences With JavaFX Composer Compared To Matisse

• Separates the view from the controller and model
• Supports a number of data sources for data binding beyond just DB and general objects
• Supports the ability to do animation visually
• Does not support doing dynamic layout visually
• All generated code is clean and easy to understand
• Handles layout for multiple screen sizes
• Supports the idea of “states” with GUI design for GUI navigation
• Can toggle the display of one or more groups (categories) of properties
• Uses a separate XML type file for storing the GUI design data (not the view)
• Does not allow JavaFX classes, JavaFX controls (custom ones), and JavaFX classes that extend CustomNode to be added to the palette

Advantages

• Can do animations visually for any JavaFX control
• Uses “state” based design
• Generates clean code that is easy to understand and can be customised
• Template system greatly simplifies building forms by having all options in one place and templates can be easily customised after they are created

What To Improve

• Need additional extensibility for JavaFX Composer with the ability to add new JavaFX controls, custom nodes and classes to the palette window
• Have a standard system for developing custom templates that can be added to the palette window
• All public properties for controls and JavaFX classes should be exposed in the properties window
• Real time display of controls that have continuous animations which are started immediately
• Provide official documentation for JavaFX Composer that covers all built in features
• Provide writing capability to all data sources that are supported by JavaFX Composer
• Use the fx source files (which contain the view) instead of the fxc files if two way editing is supported (use a single file instead of two)

Conclusion

Currently the biggest issue with JavaFX Composer is the fact that extensibility is too limited. For example a custom JavaFX control is created and a JavaFX developer wishes to use it with the tool for building a JavaFX application, by adding it to the palette window. Data binding in general is restricted to reading for some data sources (JDBC, File System, File, HTTP). With the next release of the tool one would expect that there will be the ability to write to all data sources.

Templates are a great productivity booster in JavaFX Composer since all options for creating and customising them is under one place. This is unlike wizards where one has to rerun the wizard if anything has to be changed, and not all options are covered by the wizard itself. Also each template produces code that can be easily customised when needed.

At the moment there is an awkward situation where if one edits an fxc file the corresponding fx file is not updated. Also this occurs (in the opposite direction) if one edits the fx file instead. With an fxc file it is more difficult to edit and harder to read compared to an fx file. Why have two different file types present for a JavaFX application's view? It is highly recommended that the fx file is solely used if two way editing is supported in a future release.

Why Oracle Should Dump JDeveloper For NetBeans (Update)

This is going to be a very short post. Oracle have announced in their Sun Product Support FAQ that they are endorsing NetBeans as an open source IDE option for the Java platform alongside Eclipse and JDeveloper. Some people have commented that Oracle have given a lukewarm response to NetBeans.

What is not certain is how Oracle are going to support NetBeans. Perhaps Oracle will be releasing plugins for NetBeans just like they are currently doing for Eclipse? This is probably a mere coincidence but NetBeans is moving to a completely new infrastructure (an announcement was made just a few days after the Oracle FAQ was released), I am sure that this has nothing to do with the timing of Oracle's FAQ.

On an unrelated side note the next version of NetBeans (version 6.8), which is going to be released around December will have JavaFX support ready straight away. Also all future NetBeans releases are going to be synchronised with the JavaFX releases (current and future) which should help increase development speed, and improve stability for the JavaFX plugin.

Why Oracle Should Dump JDeveloper For NetBeans

Lately there has been a bit of speculation about what will happen to NetBeans once Oracle has acquired Sun. Personally I am one of the people who is supporting the case for Oracle to support NetBeans, and to drop support for JDeveloper. It seems to me after reading what software developers think of the idea of Oracle supporting NetBeans is that the majority of them are in favor of Oracle supporting NetBeans, and dumping support for JDeveloper. Also many software developers expressed the wish for Oracle to take the best of JDeveloper (namely the DB support) and incorporate it into NetBeans itself.

When considering whether or not to support JDeveloper or NetBeans the following needs to be taken into consideration:

• Quality of support for development of JavaFX applications
• The ability of the IDE to support the big picture (supporting things that will make a difference in the long run for software developers)
• Support of widely used software development techniques (eg Agile development, Test Driven Design (TDD), team collaboration)
• Level of support for Polygot programming
• General IDE platform support
• Support for different types of software development (mobile, web, desktop, TV)
• User uptake of the IDE and IDE platform

JDeveloper Advantages

• Very good support for enterprise software development (for web development)
• Comprehensive support for software diagramming
• Reasonable built in diagnostic tools
• Ready to use out of the box for web development
• Very good support for developing DB based applications
• Good performance

JDeveloper Disadvantages

• No support for mobile and TV development
• Poor support for desktop development
• No support for Polygot programming
• Does not support JavaFX development
• Very limited uptake of IDE and IDE platform
• IDE platform is mainly used in some major Oracle products

NetBeans Advantages

• Reasonable support for enterprise software development (for web development)
• Very good support for desktop, mobile and TV development
• Reasonably good support for JavaFX development (currently #1 IDE) *1
  
• Very good support for Polygot programming (currently supports JavaFX Script, Java, Ruby, PHP, Groovy, C/C++)
• IDE and IDE platform are very widely used (high uptake among businesses and software developers)
• Very good diagnostic tools (including profiler and debugger)
• Excellent usability and out of the box experience
• Reasonably good performance

NetBeans Disadvantages

• Limited support for developing DB based applications
• Limited support for software diagramming

Some major questions remain on the very existance of JDeveloper.

• Why did Oracle create JDeveloper when they could have used Eclipse or NetBeans instead?
• Why is JDeveloper designed to be similar to NetBeans (eg with the user interface)?
• Why does JDeveloper have such poor adoption rates compared to NetBeans?
• Why is Oracle taking such an interest in the NetBeans IDE platform when it directly competes with JDeveloper's IDE platform?
  

For the first time the development of the JavaFX NetBeans plugin has been syncronised with the general development of the NetBeans IDE. It is expected that when NetBeans 6.8 is released that a JavaFX bundle will be available at the same time (on the official downloads web page). Such a change will further bolster the commitment NetBeans has to supporting JavaFX development, and will bring about stronger support in the future. Since Oracle is going to support JavaFX (in a big way) they will find themselves in an very difficult situation should they not support NetBeans (*1).

With the current situation of NetBeans not lagging far behind Eclipse (*2), and the fact that JDeveloper is not one of the top three IDEs is there really room for a 4th IDE (apart from NetBeans, Eclipse, IntelliJ Idea)? Is Oracle willing to get offside with software developers by not supporting NetBeans?

There is a potential risk that if Oracle does not support NetBeans then there could be a mass migration of developers from the Java platform to the .NET platform. Some reasons for this are:

a) NetBeans is more similar to Visual Studio than Eclipse. Why would NetBeans users go to Eclipse when Visual Studio is more familiar? Already there are many Java developers that are doing some software development part time on .NET. Many software developers consider having to use Eclipse (for development on the Java platform) a major step backward from a quality perspective.

b) Possible perception by some software developers that Oracle is not acting in the best interests of the Java platform by removing a major choice, that helps move the platform forward. One can see some of this in the NetBeans Users mailing list, it could be the tip of the iceberg.


*1 - As indicated in an informal poll conducted by Jo Conner
*2 - As indicated in an informal poll by Jo Conner and in a recent poll on java.net