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.

JFX Blocks (Core) 0.2 Released

On the 15th of December (NZDT) JFX Blocks (Core) 0.2 was released on Kenai. This release covers the following:

• General utilities
• Application specific utilities and the basic part of the application lifecycle
• Basic IO facilities (reading from an InputStream and writing to an OutputStream)
• Lookups of resources in Storage and in the application's JAR (has a basic lookup system)
• Type converter for handling conversions between reference and primitive types (especially handy when using parts of the Java API that expect and/or return a primitive type)

Do note that this release has not been tested on the mobile side since there is no JavaFX mobile emulator for Linux at the moment. Temporarily provided with the release is a mixin for creating test cases (for Unit Testing) which will be removed with a later release of JFX Blocks (Core). As for samples there is a single one that will be released on Kenai soon. In many ways the JFX Blocks release pushes the boundaries of what JavaFX is capable of, and even exposes some areas that need to be addressed (e.g. the need for a Map data type).

Feel free to provided feedback since this is an experimental release that is exploring how to best provide a library to meet the needs of JavaFX developers. It has only just scratched the surface with meeting some of these needs. In particular the core part of the library is trying to address common functionality that a JavaFX developer needs in a new or existing JavaFX application.

Current Status On JavaFX 1.3

Some news has been reported from the Devoxx 09 conference including what is currently happening with JavaFX. A lot of people who have been to the conference have reported that there will be a JavaFX GUI designer for NetBeans. It has been reported that the GUI designer will be part of the upcoming NetBeans 6.8 which is due to be released on the 10th of December (approx), unless there are any major delays. What is currently unknown about the GUI designer is whether or not it supports JavaFX 1.2, we will soon see if it does.

Some people at the conference have also reported that some of the new JavaFX 1.3 controls were demonstrated using the GUI designer for NetBeans. The major question is will JavaFX 1.3 come with NetBeans 6.8? Currently there is no official word on exactly what new controls will be included in JavaFX 1.3. What is an important question though is will the GUI designer handle the visual design of animations? Also how does the GUI designer differ from the JavaFX Authoring tool?

Prism may actually be the new JavaFX runtime starting with JavaFX 1.3? This is certainly confusing as I originally thought that prism was only a rendering system, all will be revealed when JavaFX 1.3 is released. One person who reported on the Prism demonstration at Devoxx mentioned that it is lightning fast performance wise. It will be interesting to see how that performance scales when there are many nodes on the scenegraph and/or a lot of binding is involved.

Unfortunately there is no official word on when the JavaFX mobile emulators will be released for Linux, although there is the old screenshot that shows the JME (Java Mobile Edition) 3 SDK in action on Linux. Hopefully the mobile emulators will be arriving soon. As always there is nothing official being released about the exact release date for JavaFX 1.3 (it will be released as soon as its ready – good things take time :<) ).

Oracle wise (not the actual company) I think that JavaFX 1.3 will most likely be released around the middle of December after the release of NetBeans 6.8. Again I am just repeating what I have mentioned in a previous post. It will be most interesting to see exactly when JavaFX 1.3 is released. Apparently JavaFX 1.3 will be targeted for release around Jan/Feb 2010 (Jonathan Giles mentioned this in a Twitter) which is a long time away. Prism will most likely not appear in JavaFX 1.3, but will be demonstrated at JavaOne 2010. A possible reason for this might be that Prism will be handling full 3D in the next release of JavaFX after SoMa.

Introducing JFX Blocks

Introduction

Often there will be parts (blocks – see further down for an explanation) that you want to add to an existing or new application. These parts are missing items of functionality which make the application complete. Today's issues often revolve around being able to quickly and easily find parts that adequately satisfy the functionality that is missing without adding bloat.

But when some parts are found you often find yourself in the situation where other parts have to be used, and/or some prior configuration (significant amounts) is required before using it. Frameworks are extremely poor when it comes to supplying what you need since there is additional baggage that has to be handled as mentioned above.

How does one grab what they need without requiring anything else? A key answer to this is with platform libraries since they do not require you to use what you don't need. Instead the libraries underlying design (eg through loose coupling) permits software developers to use only what they need, and not what they don't want.

An inspiration of this is the NetBeans Platform because the designers have taken into consideration that every application is different in terms of its requirements, and have designed the platform as such that if anything else is required it has sufficient design reasons for including it (eg makes it easier to implement a given piece of functionality).

Another issue is being able to easily integrate a part into an existing application. Especially if this application is used by the masses. Difficulties arise when significant changes need to be made in order to incorporate the part. In this situation you would go for a different part (from a different supplier - see further down for an explanation) provided there are some choices out there.

Certainly we are starting to see the emergence of platform libraries as a trend away from frameworks. So you could be mistaken for thinking that libraries are back with a vengeance. Indeed that is exactly what is occurring since software developers are after a balance between flexibility and simplicity when building applications.

JFX Blocks is designed to quickly and easily build new JavaFX applications (mobile and desktop, not mobile web), and add functionality to existing JavaFX applications. Currently JFX Blocks is at the design stage therefore any core functionality that is mentioned may change.

Main Aims

• Emphasise a declarative approach to building applications with a focus on what is needed

• Use mixins as “building blocks” to easily build against other existing code

• Minimise or remove the need for configuration before using a “block”

• Provide default behaviour for every “block” so it is usable straight “out of the box” in a new or existing application

• Emphasise the use of design to provide “blocks” that produce huge benefits with little effort

• Maintain high documentation standards that incorporate an extensive use of examples (samples) for getting started

• Minimise the use of tight coupling

• Maintain high coding standards

• Provide core functionality that will work on both mobile (not mobile web) and desktop applications without any major changes (JFX Blocks common profile)

Terminology

• Block – A self contained piece of functionality that is loosely coupled (a mixin)

• Container – Contains a set of blocks that handle a specific (unique) area (a JAR)

• Blueprint – Like a block except it contains no default behaviour and it only specifies how to structure something (a mixin that is like a interface)

• Connector – Enables a block to be “connected” to an application (a class)

• Supplier – Designs and creates the blocks/containers/blueprints/connectors

• Builder – The user that builds or partly builds an application using what is provided by supplier(s)

Core Functionality

• A basic (generic) lookup system that can obtain physical files, JAR resources

• IO (Input/Output) utilities

• Factory for controlled creation of “blocks”

• Handle all aspects of the application's lifecycle (eg startup, shutdown, resource loading, setting up user settings)

• A basic (generic) persistence system for general data, program and user settings

First Impressions Of Ubuntu 9.10

Lately you might have noticed that I haven't made a post for quite some time. The reason for the delay is because of some mysterious display problems with the previous version of Ubuntu (8.04 LTS) that I used. Eventually the problems reached a point where the OS had to be reinstalled, and it was a great opportunity to make a clean install of Ubuntu 9.10. After all with the glowing reviews of the OS hitting the web I thought that it would be reasonably smooth sailing with getting the current version of Ubuntu installed.


Display Woes

Smooth sailing wasn't to be the case with the live CD failing to display anything at all. In order to get something displayed the resolution was changed through the use of two keyboard shortcuts (Ctrl+Alt++, Ctrl+Alt+-). Normally most people (non technical) would give up at this point so Ubuntu was not making a good impression so far. At that point the installer could then be started.

Luckily the install went very smoothly and after a reboot everything seemed to be going fine until.... more problems occurred. Once EnvyNG (video driver management for ATI and NVidia video cards) was installed I had tried to run it but to no avail. It turns out that one has to install the envyng-qt package since envyng-gtk is broken. After a reboot the display was showing the CLI login prompt which was flickering for some strange reason.

When I tried entering in the username no characters were being displayed at all. This happened to be one of the most irritating parts of installing and setting up Ubuntu since many people (who have an ATI or NVidia video card) were having the exact same issue, and it took a long time to resolve (a matter of hours). Even worse was the fact that the Nvidia driver package is currently broken thus there is no GUI login being displayed.

Once the NVidia drivers were installed using the version supplied on the official NVidia website some progress was finally being made. Not all the display issues had been resolved yet since not all of the resolutions were being picked up properly. This part took the longest amount of time to resolve through trial and error with editing /etc/X11/xorg.conf. In my case I had eventually reached the point where I had to put up with the resolutions that the NVidia driver had picked up. Luckily after commenting out the "HorizSync" and "VertRefresh" lines in the monitor section, and logging in again all of the resolutions were then picked up properly.


What Is New And Different

• Many packages in the Ubuntu repositories have been updated including NetBeans, and the Sun JRE (Java runtime)
• Firefox is now at version 3.5.4
• Open Office is now at version 3.1.1
• Gnome is now at version 2.28.1
• Vastly improved general performance (start up times are so quick that they rival the Hibernate mode)
  
• The new Palimpsest Disk Utility 2.28.0 has been included, more details to follow
  
• Introduction of the new Ubuntu One service, more details to follow
• Default option to use the new ext4 file system when partitioning
• Linux kernel is now at version 2.6.31-14
  

What is most notable about the current Ubuntu release is the introduction of the brand new Ubuntu One service. Ubuntu One allows contacts, notes, and files (2GB free storage) to be synchronised with one or more Ubuntu (9.10 or later) PCs. Initially when I logged into the service (via Firefox) a message was displayed saying there was a version mismatch with the server. An OS update quickly resolved the problem with updating the Ubuntu One desktop client to handle the current server.

I would advise anyone who is using Ubuntu One on Ubuntu to use Nautilus (file browser) when uploading a batch of files, since the web client is slow and produces errors every time a file is uploaded. With the desktop client you can add directories and files to the Ubuntu One directory. For example with the joe user this is located in "/home/joe/Ubuntu One". Every time you add or remove a directory and/or file the client automatically synchronises the changes whenever your computer is connected with the service.


Another notable change in Ubuntu is the new Palimpsest Disk Utility. Palimpest manages disk partitions, and provides very handy diagnostic information on partitions and all storage devices. It is absolutely amazing what you can find out using this handy utility. For example one can find out about the current airflow temperature for a particular storage device, and can see what the normal temperature is supposed to be. Also Palimpest automatically notifies the OS if there are any major problems, and can perform some tests on the user's behalf for a particular storage device.


One other major change is the brand new refreshing Ubuntu look. This look reminds me of the JavaFX look, classy, legible, and visually appealing which doesn't take up too much screen real estate (netbook friendly).


Lastly Ubuntu's Add Software has been replaced with the new Ubuntu Software Center. When using the software center you can no longer install/uninstall a group of software at once, and more details are provided for each piece of software (including a screenshot, package name and version etc). Installation and uninstallation of software is now handled in the same window used to browse software, and one can swap between "Get Free Software" and "Installed Software" tabs with navigation being remembered with "Get Free Software".


Current Issues

Sound performance in my case is much worse than in Ubuntu 8.04. There is a very noticeable sound lag (consistent) which wasn't present before. Hopefully this will be resolved in the next batch of OS updates. Wireless networking is now a bit of hit or miss. It used to be in Ubuntu 8.04 that if the IP address was not picked up through DHCP the first time, then the second attempt would always pick up an address. However with Ubuntu 9.10 I usually have to restart the wireless router in order for an IP address to be obtained properly. Again the next batch of OS updates should resolve this.


Conclusion

For people who have an ATI or NVidia video card in their machine, and are currently thinking of installing Ubuntu 9.10 are advised to hold off until Ubuntu 10.04 LTS arrives. The reason for this is because 10.04 is a long term support release which is supposed to be much more robust for hardware support, and OS stability. If your machine contains an Intel video card then 9.10 is for you since many improvements have been made with supporting Intel video cards out of the box.

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

Should There Be A DB API For JavaFX?

I have identified a possible gaping hole when it comes to developing mobile JavaFX applications. Currently there is no DB API that can be used for accessing a database on a CLDC (mobile Java) mobile device. With the mobile part of JavaFX currently targeting mid to high range devices (mobile phones and smart phone) it would make sense to have a database on the devices. After all these devices would have enough resources to run a simple database (one with reduced features and capabilities, compared to its desktop version).

So it is time to start the debate on a DB API for JavaFX. Lets say hypothetically a DB API was to be designed for JavaFX. This DB API would have the following design considerations:

• Provide a consistent API that can provide basic features across all hardware platforms (desktop, mobile, TV)
• Allows advanced DB features to be accessed by desktop JavaFX applications only
• Minimises its footprint and provides as many features as possible, without using too many resources on mobile devices
• Allows seamless conversion between JavaFX Script and DB data types
• Provides reasonably good performance (including on mobile devices)
• Can easily allow syncronisation of data between the JavaFX application and the database in very few steps
• Provides the cabability of querying the DB for internal information without requiring the JavaFX developer to describe the DB structure beforehand
  

Database API Advantages

• Can use a database with a CLDC profile device (mobile JavaFX uses CLDC as the base)
• Can easily use all JavaFX Script and JavaFX features (eg binding, triggers, functional programming)
• Provides an opportunity for JavaFX to gain a major advantage over its RIA rivals
• Can take advantage of Oracle's excellent DB design expertise (when the acquisition of Sun goes through)
• A single DB API that can be used across all hardware platforms (desktop, mobile, TV)
• Able to populate JavaFX controls (both visual and non visual) quickly and easily with very few steps
• Seamless conversion between DB and JavaFX Script data types
• Reasonably good performance with JavaFX having direct access to the DB

Database API Disadvantages

• Will require JavaFX developers to learn a completely new API
• Generics and reflection will not be available to incorporate into the design of the DB API
• DB API will require existing DBs to supply new drivers
• A new DB may need to be created from the ground up to work accross all hardware platforms (incl with CLDC profile devices)
• May require existing DBs to adjust their design/implementation in order to be compatible with the DB API
• Very challenging to design and implement an effective DB API (may take at least a year before it is ready for production use?)

Now the "should there be a DB API for JavaFX" could very well become one of the biggest JavaFX debates of the year. Currently the DB API for JavaFX should not be considered a high priority at the moment, since JavaFX is mainly aimed at creating graphical applications. Therefore stuff like 3D support is a much higher priority for inclusion in JavaFX.

I intend to make it very clear that I am not a member of the Sun JavaFX team. What I have mentioned above is my own opinions and in no way reflects the opinions of the Sun JavaFX team.

What Next For JavaFX? (Update)

After looking through the bug system for JavaFX the majority of changes/additions for the next release are with the controls. Do note that the details on what controls are available may change. Here is the list of controls that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^).

• Grid Layout (+)
• Spacer (+)
• Separator (+)
• Menu (+)
• Menu Button (+)
• Custom List Cell (*)
• Search Box (*)
• Password Box (+)
• Text Area (+)
• Table (+)
• Spinner (+)
• Dialog (^)
• Multi Style Text Area (*)
• Popup (+)
• Tooltip (^)
• Status Bar (*)
• Tree (+)
• Tool Bar (*)
• Split Menu Button (*)
• Choice Button (^)
• Border (^)
• Split Pane (-)
• Combo Box (+)
• Scroll View (+)

As you can see there are quite a range of controls for the next release! However there is no calendar and tab controls, and some of the controls mentioned above may appear in the internal com.sun package instead. Also note that any controls that end up in the com.sun package are to be considered experimental, just like all the other APIs in com.sun. Luckily from the community there is a Calendar Picker control that is good enough for production use, even though it is currently in beta. For the tab control there is nothing present from the community although it is non trivial to create compared to the calendar control. I do wonder if the Grid Layout control is in fact a new layout.

On to the new and enhanced functionality the majority of the functionality is in the graphics area. Here is the list of functionality that will either, be in SoMa (+), not in SoMa (-), highly likely to be in SoMa (*), or may be in SoMa (^). Do note that this list may change as more information is known about what will be included/not included in SoMa.

• Stage level keyboard and mouse event handlers (*)
• Cloning/duplication of nodes (*)
• Built in callback function variables for state change notification on all controls (+)
• Control key functions are supported in TextBox control (+)
• Controls can be autosized (+)
• 3D transformations for 2D graphics nodes (+)
• Support for 3D bounds (+)
• Can use an image as Paint with 9 slice scaling and tiling for controls (+)
• Perspective and Parallel camera classes for 3D perspective transforms (+)
• Support for 3D rotations (-)
• Non visible controls do not recieve mouse clicks (^)
• Performance tracker for Prism (+)
• Camera/video and microphone capture (-)
• Can remove a parent from a node (+)
• Event bubbling/filtering (-)
• Pixel access (-)
• Support for maps as a core language construct (-)
  

Based on the 3D graphics functionality for the next release JavaFX will start to develop basic support for doing 3D graphics. Currently think of it as 2.5D where JavaFX is going through a transitional phase. Expect the next release after SoMa to have proper support for basic 3D graphics. Just imagine all the interesting possibilities with 3D graphics for JavaFX apps on desktop, mobile and TV :). There will definitely be other functionality that gets included in SoMa where there is no publicly available information about it.

Expect the JavaFX 1.3 release to not be too far away since the JavaFX TV plugin for NB (NetBeans) has been ready since Sept 14, and is going to be available when the JavaFX 1.3 NB plugin is integrated with the IDE. Already the installers are currently being developed for SoMa. It is only a matter of time (in days?) before JavaFX is released.

Coding Conventions For JavaFX Script

With so many people developing applications using JavaFX Script recently it is time to look at some coding conventions. These conventions will include coding standards and best practices. Below I will establish coding conventions that are applicable to JavaFX Script, many of these will come from Java's coding conventions. Remember that what I am about to mention acts as a guide and should be followed where it is applicable.

Naming

Variable and function names should be in camel case (eg isInitialized). Constant names should be in upper case with each word separated by an underscore (eg TIMER_DURATION). Class and Mixin names should be in title case (eg AppUtils). Do note that in JavaFX Script both variables/constants and functions all share the same namespace, therefore you need to name carefully.


Ordering

In a JavaFX Script source file (.fx) the following should be ordered as follows:

1. Source file documentation
   
2. Class/mixin documentation
   
3. Class/mixin
4. Class/mixin constants
5. Class/mixin variables
6. Class/mixin initialisation blocks (init then postinit)
7. Class/Mixin functions

Functions should be ordered by functionality, eg:

function func1(arg1)
{
}

function func1(arg1, arg2)
{
}

function func1(arg1, arg2, arg3)
{
}

function func2()
{
}

When defining a multiple functions of the same name ensure that the function arguments are in exactly the same order in to avoid confusion (see the example above).


Indentation

In general 4 spaces should be used for indenting code. Avoid using lines that are longer than 80 characters, wrap up long lines instead, eg:

function aFunction(argument1, argument2, argument3,
    argument4)
{
}

Long lines can be wrapped by the comma, open perenthesis characters.


Documentation

Preferably all public parts of the API should be documented since other people may use the API in their code. Only comment parts of the code that are not clear from reading it. Where ever possible use clear naming for classes, mixins, functions, variables and constants that indicate exactly what it does. This will help cut down on comments which can quickly go out of date through major code changes. Only include useful information in the comments that make it clear what a piece of code does, and why it is done that way. When handling exceptions that are going to be ignored always including a comment about why it is to be ignored.

Place comments just above the code being documented, not at the right hand side of the code, eg:

// Duration in seconds.
def DURATION;

Declarations

Place no more than one statement per line (this also apples to variable and constant declarations). Variable and constant declarations should only be placed at the beginning of a function, init, postinit, and class/mixin block. Do not declare variables and constants when they are first used (it can confuse people) like this:

if(arg1 > arg2)
{
    var temp;

    temp = arg1;
}

It is good practice to initialise variables when they are declared in order to make it clear what starting value or reference they have.


White Space

Each declared variable, constant, function should be on their own line, and two blank lines should separate variables/contants and blocks/functions, eg:

class aClass
{
    def const1;
    def const2;
    var var1;
    var var2;
   

    init
    {
    }

    postinit
    {
    }

    function func1()
    {
    }

    function func2()
    {
    }
}

Use two blank lines to separate class/mixin definitions in the source file. Each operator that is used needs to be surrounded by a space, eg:

minutes = seconds * 60;

Scoping

Keep internal class/mixin variables and constants private by omitting a scoping keyword unless there is a good reason to expose them externally. If a variable is to be read but not changed externally then use the public-read keyword, else if a variable is only allowed to be set once externally during object creation then use the public-init keyword. If a class/mixin variable or constant is meant to be accessed by sub classes/mixins then use the protected keyword.


Best Practices

• Try to keep recusion in each function to no more than 3 in order to make it simple to understand and maintain
  
• Try to keep nesting to no more than 3 levels with each object literal in order to make it clear what the sequential order is
• Do use variables to reduce object literal nesting by having object literals refer to them instead of embedding an object literal
  
• Avoid using names for variables, constants, functions and classes/mixins that are reserved by JavaFX Script if at all possible
• Minimise the use of binding since it can degrade performance in an application
• Use binding where a variable's value has to be constantly kept in sync with another variable since it reduces unessesary boilerplate code
• Use perenthesis to clarify the operating order for an expression (eg if((a == b) and (c == d)))
• Only use a single return statement (which is the last line) in a function, this makes a function easy to follow in sequential order
  

Ten Interesting Aspects Of JavaFX Script

With the JavaFX Script programming language being cited by many as one of JavaFX's main strengths it is time to look at the language's interesting aspects. Some aspects will pleasantly surprise you, while others will come as a shock. Here are the 10 interesting aspects of the language.


1. Built-in support for generators

Comes in handy for generating multiple items. In particular it is commonly used for generating multiple nodes for use in layouts. Each generated node may be customized differently to accommodate different data being supplied for display.


2. Can run actions at a later time

Useful for displaying splash screens properly when there is some background processing going on. Below is some sample code that demonstrates this (in a script):

// Splash screen is displayed here.

public function run(args: String[]): Void
{
FX.deferAction(doBackgroundProcessing());
}

function doBackgroundProcessing(): Void
{
// Background processing is done here.
// Display the main screen, and then close the splash screen.
displayMainScreen();
}

What is important to remember here is that the function you are passing to the deferAction function must have a return type of Void. The deferAction function allows the splash screen to be fully displayed, and we can have the main screen displayed just after the splash screen is closed.


3. Can format dates in strings

Some concise syntax is provided by JavaFX Script to enable you to embed date formatting in strings. All of the date formatting options in the SimpleDateFormat class can be used, for example:

var formattedDate = "{%MM/dd/yy java.util.Date{}}";

In the above code a % char is used followed by the date format and a Date object to format a date in an expression. It may be possible in future JavaFX releases that regular expressions can be used as a string formatting option.


4. No support for static functions, variables and constants

An exception to this is with scripts, not classes. It would be interesting to know why JavaFX Script has no static support (an important design decision that was made?). Someone from the JavaFX development team would be able to shed more light on this.


5. Basic support for lookups (on nodes only)

Very handy when you do not want to keep a variable around, and want to temporarily access a node in order to run an action on it or make some changes. It may be possible that lookup support will be expanded to other areas (more general support) in future JavaFX releases.


6. Function parameters are immutable

At first this will be strange for those that have not done functional programming before. Since JavaFX Script has built in support for functional programming this makes sense. By making function parameters immutable it means that a function can safely perform operations on the parameter, without changing it thus when the program runs no funny side effects will occur.


7. Built-in support for mixins

Mixins are like interfaces except that you can define behavior in functions. Since mixins replace multiple inheritance it has made it easy to have a mixin or class inherit from multiple sources (mixins) in a predicable (clean) way. Do note that a mixin cannot be initialised.


8. First class internationalization support

This is one of the best features of JavaFX Script since it makes it a piece of cake to internationalize a program. Some unique syntax is used to make it easy to internationalize strings which hook up to a fxproperties file, for example:

Stage
{
title: ##"Window Title"
scene: Scene{}
}

The title property's value is tied to a key called "Window Title" which is prefixed by ## (indicates an internationalised string). Here is the corresponding resources_en.fxproperties file that contains that key:

"Window Title" = "Main Window"

Some people would consider this to be another form of lookup in JavaFX Script. It is very much up to debate if this is the case.


9. Built-in support for animation

It is much easier to handle animation when it can be done directly without the need for a library (less abstraction), and most properties can be manipulated via binding for use on a timeline. The unique JavaFX Script syntax provides a concise way to animate nodes quickly in a scene graph.


10. Built-in support for binding

Makes it very easy to keep properties in sync, thanks in part to the unique JavaFX Script syntax. Even better is the fact that you do not need to create any tedious, and error prone boiler code to do it which helps to reduce overall maintenance.


Some of the formatting of this blog post is incorrect since I am unable to get the editor to properly change the formatting (major bug). Hopefully this will be resolved in time for my next blog post.

HTML 5 And RIA

With so much information available on HTML 5 at the moment, in particular with the rumor of HTML 5 killing off all the other major RIA technologies (JavaFX, Silverlight, Flex). Now is a good time to discuss the advantages and disadvantages between the two. Currently HTML 5 is being touted as the one technology to do everything, however to be honest it will be good at some areas, worse in others. Certainly many people will get a reality check once HTML 5 is used in real world projects. This reminds me of when Java was introduced since in a way history is repeating itself all over again.

For the basis of this article I will be commenting on what was mentioned in the well written article titled, HTML 5 Starts Looking Real. Be warned that while the web page is loaded that you may experience a very sluggish web browser, due to the Flash ads that have been embedded in the article. So be sure to close the web page as soon as you have read the article.

In the referenced article there is a lot of coverage on openness and why it matters, the author seems to think that HTML 5 will take over because it is fully open. But there is much more to it than having a technology that is open. While I am a firm beliver in using open source as much as possible, and where it makes sense to do so, I understand that to get the best out of software development you need to have balance.

Often this balance means being prepared to use something that may not be fully open sourced. Some of the best software/technologies in use today are not fully open sourced. If a software/technology is partly open sourced does that completely stop you from utilising it? Obviously that may not be a yes answer to that question since you may see some advantages with having some parts closed sourced, even though you prefer them to be open. Although all of the RIA technologies are not fully open sourced that does not stop people from using them.

As the referenced article mentions, flexibility is another major part to take into consideration when looking at HTML 5 and RIA technologies. Especially if you need to develop a highly sophisticated applications that tie into the underlying software/hardware platform. This is going to be an area that places HTML 5 at a significant disadvantage in relation to RIAs since it will largely be constrained to the capabilities of the web browser used by the user.


Advantages Of Using HTML 5

• Can easily have search engines go through all content
• Minimal learning curve since most people already know the basics of HTML
• Cheaper budget with using any free tool that can handle HTML
• Large pool of developers to choose from when forming a development team
• Easier to deploy HTML 5 applications since HTML is supported natively by the web browser, and does not require any installation
  

Disadvantages Of Using HTML 5

• Limited ability to take advantage of new software development techniques since the choice of programming languages is limited
  
• Will take longer to evolve since it is a combination of standards that are developed by different groups
  
• User experience will greatly vary between software/hardware platforms (lack of consistency)
  
• Limited flexibility and power since HTML is constrained to the capabilities of the web browser
• Poor choice for mobile platforms since it will not take advantage of the hardware and will provide very limited capabilities
  
• Inconsistencies of HTML being implemented between web browsers (different parts of the standard are implemented)
• Performance is largely constrained to the bandwidth that is available to the user
• User may need be connected to use an HTML 5 application
• Very limited support for media formats
• Lack of good tooling to be productive in developing large sized HTML 5 applications
• Basic animation and media features
  

Advantages Of Using RIA

• Can provide a guarantee of a reasonably good user experience (consistently) between different software/hardware platforms
  
• Can evolve quickly since it is developed by a single company/organisation
  
• Able to take advantage of new software development techniques since there is a wide range of programming languages to choose from
  
• Good tooling for developing large sized RIA applications (increased productivity)
  
• Good performance and power since RIAs can take advantage of the software/hardware platform
  
• Reasonably consistent implementation of features between software/hardware platforms (including mobile)
• Good performance with access to the hardware
• Wide support for media formats
• Excellent choice for mobile platforms since it will take advantage of the hardware features and can provide a reasonable user experience
• Advanced animation and media features
  

Disadvantages Of Using RIA

• More difficult to deploy since a plugin will need to be installed first
• Deployment of RIA applications are largely restricted to software/hardware platforms that have a plugin available
• Smaller pool of developers to choose from when forming a development team
• Increased learning curve since completely new technologies need to be learned
• Search engines may be unable to go through content effectively

In general if you are planning to develop a simple application quickly that is not very sophisticated, and needs to be easily deployed then HTML 5 is a good choice. On the other hand if you are developing a highly sophisticated application, that requires a consistently good user experience then RIA is a good choice.

Also RIA should be favoured over HTML 5 if an application is going to be developed for mobile hardware platforms. Remember that a good user experience and the ability to have the application take advantage of the hardware (can be customised to the hardware), are the main considerations when developing applications for mobile.

What Next For JavaFX?

After the current release of JavaFX (version 1.2) many people will be wondering where JavaFX will be heading next. Considering that Sun is remaining tight lipped at this stage on what to expect next with JavaFX I can only speculate on what could be included in the next release. Most of my information in terms of this speculation mainly comes from the JIRA bug tracking system and JavaFX team member blogs.

It is easy to understand why Sun is tight lipped on JavaFX development when you see what is new with Flex 4. For some reason there is no content being displayed with the referenced article, you may have better luck than I did. One cannot help but wonder if Adobe are obtaining the majority of their inspiration from JavaFX, it seems highly likely they did. Honestly I think that they have been intimidated by the recent success that JavaFX is currently enjoying, and are trying to bring some of that success to Flex. Flattery is the biggest form of imitation.

Based on what little information I have obtained so far this is what is most likely to appear in the next release of JavaFX (version 1.3, codename SoMa):

• New graphics/rendering system (named Prism)
• Basic 3D graphics APIs (from Prism)
• Improved graphics performance (from Prism)
• Use of GPU for graphics rendering (from Prism)
• New 3D graphics system (based on OpenGL ES) that can be used on desktop, mobile, TV (from Prism)
• Beta version of the highly impressive JavaFX Authoring tool (for Graphics Designers only - may be of use to Software Developers?)
  

The majority of improvements are in the area of graphics and performance like the previous release. After looking at the above list you are probably thinking that everything that is likely to be included comes from Prism. Just to give a quick background on Prism, it is a completely new graphics system built from the ground up to take advantage of the graphics hardware in the target machine. Prism was development around the same time that Scenario (the current graphics system for JavaFX) was being developed.

As you would expect with Prism using the graphics hardware (eg GPU) you should be seeing significantly better framerates, and less memory being used as a result. Currently many people are experiencing serious performance issues with the number of nodes being added to a scene (the biggest problem with Scenario). The more nodes that are added the slower the JavaFX application becomes, and the more memory that is used as a result. Eventually if one adds too many nodes this can result in the dreaded "out of memory error", sound familiar? Most of us that are developing applications using JavaFX can afford to wait for the next release, which does not have this issue since Prism is not affected by this.

It is a big if with the beta release of the JavaFX Authoring tool, but I would rather see a polished product as opposed to one that has clearly been rushed to the door too soon. Still it is highly beneficial to get the authoring tool released early for feedback so that it can become a high point of choosing JavaFX. After all we should aim to ensure that the authoring tool is the best designer tool around, PERIOD. It is time to target Flex Builder (based on the NetBeans GUI builder - Matisse) since we can do much better than what Adobe is currently doing.

JavaFX 1.2 On Linux (Update)

Much to my surprise after performing some recent Ubuntu updates Java Web Start suddenly works again. I suspect it may be related to the GNU Java package, which was promptly uninstalled after experiencing problems compiling Java projects in NetBeans. By chance another attempt was made to run a JavaFX application through Web Start which worked perfectly without problems.

For those of you running JavaFX applications on Linux I would highly recommend you run them through Web Start. The reason for this recommendation is that the applet plugin for Firefox needs to become more robust. That is applets need to start without freezing the web browser, and more detailed feedback needs to be provided on the applet's loading progress (including the downloading of required resources). At least with Web Start you obtain a reasonably good level of feedback with the loading progress of an application, and if the application freezes then nothing else will be directly affected.

On the good news the Java Mobile 3 SDK is in the works for Linux. There is a screenshot of the SDK in action with one of the mobile emulators running via NetBeans. At the moment the JavaFX Authoring tool (for designers only) is currently in development. This tool will allow JavaFX applications to be designed visually (including the animations and bindings). It is a shame that the tool is not being targeted towards JavaFX developers since much of what was demoed at JavaOne 2009 is exactly what developers will be involved in doing daily. Certainly one would expect that the tool will be available on Linux since it is written in a mixture of Java and JavaFX. Details are currently sketchy on the tool but expect to hear more about the tool as soon as its released (as a stable version) at the same time JavaFX 2.0 (codename SoMa?) is released towards the end of this year.

I am predicting that if the JavaFX developers needs are met by the JavaFX authoring tool then they will be using it regularly. Not ideal unless there is a similar tool being released at exactly the same time for developers. In the worst case scenario the tool would need to satisfy the following developer requirements:

1. Allow assets (resources) to be accessed and stored through local storage (eg hard disk, USB key)
   
2. Generate fx source files for the view that are loosely coupled from the controller and model
3. The generated fx source files for the view must be easily customised by the developer, but must be readable in the tool after being customized
   
4. Be directly integrated with a set of usable mobile emulators that support all of the required JavaFX mobile APIs (including the set of APIs that make up the Mobile Services Architecture JSR)
5. Have "Matisse" like visual layout (a real must for custom dynamic layout)
6. Can easily add additional visual (and non visual) JavaFX controls to the control palette without writing any extra code just like in NetBeans
   
7. Customized visual binding via scripting (through JavaFX script)
8. Automate the tool through visual macros that can be customized at the code level (Scala is a possible candidate here)
   

If anyone has any ideas on what to include in the list please include it in the comments for this post.

JavaFX 1.2 On Linux

Yesterday I had an excellent opportunity to give JavaFX 1.2 a spin on Ubuntu Linux (8.04 LTS - Desktop Edition). A 30 Kbps ADSL connection is used as the Internet Connection. All performance figures are informal and will greatly differ between Linux desktops. Some additional media codecs have been installed, which provide support for additional media file formats (including WMV and WMA) for GStreamer in Linux.

Before installing the JavaFX 1.2 SDK I installed JDK 1.6 (Update 14) which is a requirement for the JavaFX SDK. However the Java browser plugin had to be configured afterwards for Firefox, which is not as difficult as many might think it is. It is as simple as creating a link in Firefox's profile folder that points to the plugin itself. Do note that it is highly recommended that you setup the JDK_HOME and JAVA_HOME environment variables. After installing and configuring the JDK a test was in order to see if the browser plugin was properly functioning, which I can safely say passed with flying colours. You will need to have the Java browser plugin working in order to run most of the sample JavaFX applets on the official JavaFX site.

Installation of the JavaFX 1.2 SDK went smoothly, it was a matter of running the shell setup script and moving the SDK folder to the correct location. What I was most impressed with in terms of installation was the NetBeans IDE (with built-in JavaFX support). The experience was totally seamless, even the JDK was picked up by the IDE's installer and the JavaFX SDK was already included with the IDE. Right from the start of starting up the IDE I was able to create and run a JavaFX application in 15 minutes which included basic multimedia support.

In terms of multimedia support on Linux as many Linux users will know, is a hit and miss affair. When it came to testing multimedia support with JavaFX was was pleasantly surprised with the experience, since it had exceeded all my expectations. The following media formats that I had tested with my own JavaFX application work out of the box:

• WMV (WMA has not been tested but is most likely to work)
• MP4
• OGG
• FLV

Only the MP3 media format did not work as expected. During the first 3 seconds of playing an MP3 file everything sounded fine until stuttering occured. JavaFX has a built-in events to handle the stuttering effect. I have not used the event (inside the application) in light of the problem with the MP3 file. What I found strange is that on the official JavaFX site the JavaFX media player is used on Windows to play the videos, but on Linux I am forced to use the Flash media player. This appears to be due to the faulty platform detection code because I saw the following message on the web page, "Note: you have reached this page because you are on a platform not currently supported by JavaFX. If you think you have reached this page in error, please click here.".

The biggest highlight on the JavaFX SDK release for Linux has to be the performance, which is absolutely outstanding. From running applets to desktop applications I hardly noticed any pauses or freezes while the programs were running. My hat goes off to Sun for this since this is certainly one area where JavaFX can not only get ahead of other competitors, but also increase adoption by developers.

I personally decided to stress test the Java browser plugin by running 10 JavaFX applets (from the Samples section of the official JavaFX site) simultaneously. Most users will not run that many applets at once, however it is still useful to see how performance and stability fares when multiple applets are running. Firefox did not crash once when all ten applets were running and the reserved memory usage for the plugin (java_vm process) was not too bad at 153.2 MB. On average 15.32 MB is reserved for each applet. What needs to be done in memory usage though is to have memory released as soon as an applets exits (the Windows version already has this capability).

Now comes the part where many people will shudder (including me) at the thought of starting up/launching applets. In the past this has been a real archiles heel for Java desktop applications. I can proudly say after testing start times for applets (in the Samples section on the official JavaFX site) that startups are MUCH faster. In the worst case one applet took 14 seconds to startup. On the opposite side of the coin there were quite a few applets that took no longer than 3 seconds (there were even ones that only took a second!).

Upon attempting to run all sample applets (on the official JavaFX site) I found that most applets would startup and run properly. Here are following samples that do not run properly:

• Draggable MP3 Player (cannot play any MP3 music and cannot drag applet out of the web browser)
  
• Keystroke Motion (applet does nothing when applet is selected and keys are entered)
  
• Video Cube (refuses to play an FLV file whic)
  

The biggest downside for the deployment of JavaFX applets is that some of them totally freeze the web browser while starting up. If you are a user then you would totally be intimidated by this to the point where you would avoid any websites that freeze the web browser. The freezing normally occurs for no more than 3 seconds for most applets. This freezing has to be resolved in time for the next update of the JRE for Linux. By that time JavaFX developers will be ready to test deployment of applets.

As for awful surprises all JavaFX applications that I have launched through Java Web Start fail to start up at all. All of these failures have once thing in common, the MalformedURLException is displayed as the root cause of the failure. Java Web Start was not broken like this in previous releases of the JRE for Linux. It will certainly be a top priority to fix Java Web Start for Linux in time for the next release of the JRE.

Integration of JavaFX applications with the OS is a real plus. I can copy and paste text to and from a JavaFX Text Box, I can even copy and paste text via drag and drop. Do note that text cannot be selected by word with the keyboard or mouse. Creating full screen applications does not currently work properly (the title bar is missing). Maximizing and minimizing the application works as expected.

For some reason media streaming is hit and miss with the Media Box sample (on official JavaFX site). During the first few seconds of playing the video the sound plays just fine before it cuts out. The Video Cube sample fails to play the FLV file (a MediaUnsupportedException is displayed in the message) even though it is playable in my JavaFX desktop application.

Overall I would highly recommend the JavaFX SDK for software developers that are using Linux despite that fact that Sun has classified the SDK as being in Beta. In my opinion I consider the SDK to be a release candidate, but that is up for debate by other developers. Despite the deployment situation being bad developers can very comfortably create JavaFX applications right away. In the mean time look out for the next update of the JRE which should improve deployment from being bad to not too bad. By that time you can safely test the deployment of JavaFX applications.

JavaFX 1.2 is a HUGE step forward which should help with its adoption, and advocacy even though it is a little bit behind its competitors in some areas (deployment, UI building), but ahead in others (performance, component architecture, binding, cross platform support). It is very good to see JavaFX rapidly catching up to its competitors, and that Larry Ellison is extremely enthusiastic about it, to the point where he is prepared to make a full commitment (this includes development). Now it would be nice to see a SVG to FXM converter (many people are using Inkscape as an open source alternative to Photoshop - this is starting to become common place with JavaFX) with the next JavaFX SDK release, and the GUI designer which I am VERY eager to try out.

A note to Sun about support for developing JavaFX mobile applications on Linux. Linux has a very large presence in the mobile development area. Since the first versions of the CDLC and CDC SDKs (before they were rolled into the JME SDK) there has been solid support for Linux. It is very disappointing to see that there is hardly any support for Linux with the JavaFX SDK on the mobile side. Also there is no JME SDK (version 3) for Linux. I am expecting that there will be an actual JavaFX mobile emulator, as well as a release of JME SDK (version 3) for Linux by the time the next JavaFX SDK is released.

While JavaFX mobile applications can be developed on Linux (in theory) there is no way to properly test and deploy them on a mobile emulator, or mobile device. Considering that JavaFX is going to shake up the mobile development scene for the better, would it not make sense to provide a good level of support for Linux in order to have widespread adoption?