JavaFX 2 - The Good, Bad, And Ugly

Plenty of changes have been announced at JavaOne with JavaFX in relation to JavaFX 2.0. In general there are a number of good changes which generally offset the bad and ugly ones.


Good

• JavaFX APIs will be made accessible to any JVM language
• New controls (TableView, SplitView, TabView, MediaPlayer, WebBrowser, RichText)
• Prism will become the standard graphics rendering system (does hardware rendering)
• New consistent layout system
• Support for high definition media (audio and video)
• The entire JavaFX platform will be open sourced by the end of the year
• Multi-threading support
• Prism plugin (for the web browser)
• Texture paint (using images)
• Synchronised media and animation
• New WebView node for embedding HTML content in a JavaFX application
• New WebEngine (used in WebView) for parsing HTML content which produces an HTML DOM

What I most look forward to are the new controls and built in multi-threading which will really make a huge difference when developing a sophisticated front-end application. It is good to see Prism being used as the standard rendering system since it will provide significant performance benefits. Finally the full open sourcing of JavaFX is going ahead which means JavaFX will enter a “renaissance” era with innovate development by the community, greater adoption, and greater momentum. It will be fascinating to see the direction that JavaFX heads into, and its uses.


Bad

• No official language for developing front-end JavaFX applications
• JavaFX Script is no longer supported by Oracle (from JavaFX 2.0 onwards)

Although very disappointing to see Oracle drop support for JavaFX Script there is a silver lining. Since JavaFX Script is fully open sourced the JavaFX community can take over its development. Many people have been spreading misinformation about JavaFX Script being dead when it isn't. What needs to happen is for a team to be assembled in order to continue the programming language's development.

Without a doubt JavaFX Script's development will continue so people shouldn't be too hasty to switch to another language for handling the front-end with JavaFX. If anything the decoupling of JavaFX Script from the JavaFX platform will make it easier to use the language with other JVM languages. One good example of this might be using JavaFX Script for the front-end, and Scala for the back-end, just imagine the potential possibilities!


Ugly

• No clear direction for JavaFX Mobile
• Proposed alternate HTML graphics rendering system offers very little advantages in relation to the huge number of risks/downsides involved

What should be the biggest concern to the JavaFX community now is the fact that Oracle are not providing a clear direction for JavaFX Mobile. Contrary to what other people have said about JavaFX Mobile being dead that is not true. What has actually happened is Oracle have placed JavaFX Mobile for CDLC on hold. JavaFX Mobile is still going (in a different direction) but Oracle's inaction with it is very frustrating.

If Oracle is having a huge amount of trouble with working out what to do with JavaFX Mobile then they need to bring additional people on board who are experienced with mobile development. Also Oracle needs to commit on freely providing JavaFX Mobile runtimes for some of the major mobile platforms (eg Android, Blackberry, Symbian), which should have been done in the first place.

There is a bit of excitement with the HTML rendering system (alternative to Prism), which may be used for the mobile side. What many people will not realise is that the idea of being able to run JavaFX applications without a runtime, on any device supporting HTML is an idea that faces too many downsides and risks. Why would Oracle head down this path when Prism can handle mobile rendering (in 2D and 3D), consistent rendering across different devices, provide very good performance, and is already well in development?

It seems as though Oracle have rushed head long into developing an alternative rendering system with no sufficient justification, and an absent mind on the downsides and risks involved. To get an idea of the downsides and risks with the alternative rendering system that Oracle might be developing refer to the list below:

• Limited rendering performance that is dependent on the browser used
• No support for 3D rendering
• Possible delays added to getting future JavaFX releases out
• Inconsistent rendering since different browsers will be used by users
• Many features will not be available since the rendering has to be done in a browser which may not be upgradeable in a mobile device
• Huge technical difficulties involved with properly rendering JavaFX application in a browser without the need for a plugin/runtime
• If the rendering system fails to deliver then it could cause a crippling blow with getting people to use the JavaFX platform (a bad reputation – look at Applets as a good example)

Conclusion

JavaFX's future is looking very bright despite Oracle no longer supporting JavaFX Script. Next year will certainly prove to be a very exciting year for JavaFX considering the sheer number of big changes planned by Oracle. Right now the biggest concern is with Oracle not properly directing JavaFX Mobile. Even worse is the fact that Oracle are not very active in the mobile space when they need to be competitive, less talk and more action/commitment by Oracle!

JavaFX 1.2 Application Development Cookbook Review

I have been offered the opportunity by Packt Publishing to review the JavaFX 1.2 Application Development Cookbook. In this review the book will be reviewed by relevance, content, and presentation. Do note that the ebook version is being used as the basis for the review. You can find out more details about the book on the Packt Publishing website. Listed below are the chapters in the book:

• Chapter 1: Getting Started With JavaFX
• Chapter 2: Creating JavaFX Applications
• Chapter 3: Transformations, Animations, And Effects
• Chapter 4: Components And Skinning
• Chapter 5: JavaFX Media
• Chapter 6: Working With Data
• Chapter 7: Deployment And Integration
• Chapter 8: The JavaFX Production Suite

Relevance

Despite the book being released at a time when JavaFX 1.3 is around much of the book's content is still applicable to the current JavaFX release. Keep in mind that you will need to work out any differences between JavaFX 1.2 and 1.3 in relation to the code samples throughout the book. Also some of the code samples may not run at all in JavaFX 1.3.

Considering that the book is a technical cookbook I was expecting all of the recipes to be tailored towards technical tasks instead of getting started type tasks. There are some recipes in the book which turn it into more of a tutorial/getting started type of book. As a result the book loses a bit of focus on being a true cookbook, which means there are less recipes covering technical tasks that could have been included. A true technical cookbook should not include getting started type recipes.


Presentation

In the ebook version the book cover is aligned incorrectly and is not ideally suited to the book itself. All titles are pleasant to the eye, and every screenshot clearly shows the final result for each recipe. The formatting styles utilised in the book are consistent although the headings are a bit squashed in the ebook version (not enough white space used before and after each heading).

Good fonts are used for the text and headings which make them very easy to read. All the code samples could do with some basic colour syntax highlighting to make them even easier to read. At least the code is indented correctly and can be easily copied from the ebook to an IDE for developers to try out.


Content

A good title and basic description is provided at the beginning of the book. When it comes to content the book comprehensively covers most topics that you would expect it to cover. However it is surprising to see that there are no recipes covering the parsing of XML and JSON files, and back-end multi-threading for instance. Clearly the content of the book is geared towards beginner to advanced JavaFX developers.


Navigating the book was very easy and anyone can jump to a particular recipe provided they have the required knowledge (as outlined under the recipe's Getting Ready section). This is due to the well thought out structuring of the book. Very good explanations are given for the technical aspects that can be learned while reading the book. Especially in the excellent How it works... sections where it walks you through how something is done in a methodical manner.


Conclusion

Overall I would highly recommend this book for beginner to advanced JavaFX developers as a place to find out how to do specific tasks via the recipes in the book. Beginner developers would benefit from going through some of the basic recipes in order to become familiar with JavaFX, in addition to going through a getting started type book. Advanced developers would benefit from understanding how to do the more advanced recipes, which cover some of the advanced uses of JavaFX.

JavaFX Improvements

Plenty of improvements have occurred since JavaFX 1.3 was released. It is interesting to see where the majority of improvements have occurred as well as where we might see other ones in the future. I can only speculate at this point as to what improvements might appear in JavaFX 1.4 (Presidio). Here are some of the improvements that have occurred since JavaFX 1.3:

• Faster cold and warm startup of JavaFX applications
• Default splash screen for JavaFX applications which includes a built-in progress bar
• Custom splash screen support for JavaFX applications
• Basic custom node/control support in JavaFX Composer
• Easier debugging of JavaFX applications
• A new set of data orientated JavaFX controls in JavaFX Composer
• Fragment design support in JavaFX Composer
• New Grid template in JavaFX Composer
• New CSS reference
• Updated JavaFX API documentation

As for what the main theme might be for the next JavaFX release I am guessing that it will be on “going back to basics”. With the basics this would include expanding JavaFX Script to include additional basic types, basic low level graphics access at the pixel level, date/time APIs, additional controls, basic front/back end multi-threading system, basic 3D support, and an expanded event handling system. The majority of this would heavily rely on Prism being stabilised and becoming the standard JavaFX rendering system for the next release. Below is a list of what is currently being considered for inclusion in JavaFX 1.4:

• Stroke positioning
• Text Editor control
• Split View control
• Map data type for JavaFX Script?
• Open URL in web browser
• Flexible/common method to specify resources
• Theme support
• Table View control
• Basic built-in multi-threading system?
• Z depth sorting (buffering)
• Full 3D transforms for 2D objects
• Multi directional text
• Customisable dialogs (eg for Alert)
• Palette control (part of foundation for IDE type applications)
• Support for dialog boxes (create your own)
• Spinner control
• Fill and stroke transition
• Stage level events
• HTML support for text (HTML control?)
• Support for 3D bounds

Not surprisingly new controls are in the list, including some long awaited ones. However there doesn't appear to be any mention on 3D primitives (essential to proper 3D support), or on APIs for accessing graphics on a low level which is increasingly becoming a major issue. Considering how many improvements depend on Prism being stabilised and becoming the standard rendering system, there is a bit of urgency with getting Prism ready in time. According to Oracle's 90 day release policy for JavaFX a new release is due. What will be seen in the next JavaFX release?

JFX Blocks (GUI) 0.3 Released

JFX Blocks (GUI) 0.3 has been released on Kenai. Here is the list of changes for this release:

• Five new controls introduced (AutoComplete, MediaPlayerBar, MessagePanel, NavigationTrail, SearchBox)
• New ArrowPoint shape
• Navigator has been renamed to NavigatorBlock (now located in org.jfx_blocks.gui.block)
• Basic search functionality provided by SearchProviderBlock (located in org.jfx_blocks.gui.block), which will be moved into the next JFX Blocks (Core) release
• Removed Toolbar control since JavaFX (ver 1.3 onwards) now covers it as a preview control
• MediaPlayerBar control is only available in the desktop profile due the use of desktop only GUI multithreading (may change in future releases)

In order to deliver a MediaPlayerBar control that would work as intended the FX.deferAction function had to be used. The deferAction function is only available in the desktop profile so it created a bit of a problem. Either not deliver the control at all or make it only available on the desktop, I chose the latter. As a result it exposes the less than ideal situation with GUI multi-threading for JavaFX where options are limited, and even worse the only option works with desktop JavaFX applications provided Decora is used.

With Prism due to replace Decora (as the standard graphics rendering system) soon a completely new multi-threading system will need to be built for JavaFX. Otherwise there will be some show stopper situations that will prevent a JavaFX application from being developed/deployed. For instance having more than one change made to the GUI at the same time without freezing the application. If the JavaFX team needed a good reason to kick start the initiative sooner rather than later then here it is!

Internal JavaFX APIs

Some of the best JavaFX functionality can be found with the internal JavaFX APIs. Be warned that the internal JavaFX APIs are subject to change without warning and should not be relied upon as a result of this. As an additional warning the internal APIs do not go through the rigorous testing that the public ones do, so you're essentially on your own if anything goes pear shaped. Below are some interesting APIs (in JavaFX 1.3) that are worth keeping an eye on since they may influence what appears in the next JavaFX release, or any other future JavaFX releases.


PerformanceTracker

Recently some work has been done in developing a system to measure performance for a JavaFX application. I do not currently have a JavaFX application that can be used for trying out PerformanceTracker (located in com.sun.javafx.perf) thus I don't know if it works. At the moment PerformanceTracker is restricted to reporting FPS and basic performance logging so it is still in the early stages.

To start with PerformanceTracker it will need access to a Scene object, eg:

def perfTracker = PerformanceTracker.getSceneTracker(scene);


FXRobotFactory

One of the most interesting parts of the internal JavaFX APIs in that it may be an indication of some useful functionality which could appear in a future JavaFX release. Just like AWT's Robot class FXRobotFactory (located in com.sun.javafx.robot) handles UI automation which is very useful for automated UI testing. In fact FXRobotFactory's design is almost identical to Robot so if you have used Robot in the past you will be right at home. Just don't expect FXRobotFactory to be relying on Robot though since it is completely independent (built from the ground up).

After attempting to try out FXRobotFactory it doesn't seem to work with Decora, but it may work with Prism (haven't tried). To start with FXRobotFactory it will need access to a Scene object, eg:

def robot = FXRobotFactory.createRobot(scene);


DateTimeEngine

After giving DateTimeEngine (located in com.sun.javafx.runtime.date) a spin I have been very tempted to use it with some of my JavaFX applications. It works but with one hitch, a TimeZone object will need to be passed in in order for it to work properly. DateTimeEngine allows date/time to be manipulated/viewed just like with Java's Calendar but much simpler to use. Not much would be needed to incorporate this API into JavaFX's DateTime, which I suspect is DateTimeEngine in disguise.

Below is a very small example of using DateTimeEngine:

def dt = DateTimeEngine.getInstance(DateTime{}.instant, TimeZone.getDefault());

println("Current Date: {dt.getDayOfMonth()}/{dt.getMonth()}/{dt.getYear()}");
println("Current Time: {dt.getHours()}:{dt.getMinutes()}:{dt.getSeconds()}");


Clipboard

The biggest surprise is the internal development of this API. Who knew that there were plans to allow JavaFX applications to access/manipulate the clipboard. Since Clipboard (located in com.sun.javafx.scene.transfer) needs no basic introduction I will go on to say that it definitely works with copying/pasting text, and may work with other data types although I haven't tried Clipboard with an image for instance. However I have had the chance encounter to accidentally use it to paste a Java object in a JavaFX application, but it could not be done since the class files (NetBeans platform ones) could not be found.

Below is how you would use Clipboard to transfer a String (clipboard copy) to it, and access the first clipboard item (clipboard paste):

def clipboard = Clipboard.getSystemClipboard();

// Copy a String from stringContent variable into the clipboard.
clipboard.placeString(stringContent);
// Paste first clipboard item into the println function.
println("Clipboard Content: {clipboard.getContents()[0]}");


Conclusion

As you can see there are some interesting developments going on with the JavaFX APIs. Who knows what may appear in a future JavaFX release. Some of the internal APIs are already usable but be aware that they are not public, hence the internal API disclaimer in the first paragraph. With that said there may be a sudden flurry of feature requests in the JavaFX bug database, based on a particular internal JavaFX API that people wish to see in JavaFX publicly.

Open Source Management For JavaFX

Currently Oracle is faced with making a decision on whether or not to fully open source JavaFX. At the moment there is an unanimous voice made by the JavaFX community for the technology to be fully open sourced, via the petition started by Steve Chin. Below are some options for managing the open sourcing of JavaFX if Oracle made the decision to open source the technology (fully).

• Apache
• Oracle
• JCP (Java Community Process)
  
• Foundation

Remember that open sourcing JavaFX is a long term solution that needs to be properly managed in order to fully reap the benefits of doing so. I will be looking at the options as if Oracle have made the decision (hypothetically) that the community is after (requiring). Key factors that will influence which organisation open sources JavaFX is:

• Ease of innovation for JavaFX with incorporating new features and systems, and the speed of getting them through
• Participation of the entire JavaFX community vs commercial interests
• Development and support of JavaFX on the mobile side (with JavaFX Mobile)
• Licensing of JavaFX so it can be used everywhere front-end applications are needed
• Allowing contributions which can be previewed/incorporated in future open source JavaFX releases
• Promoting JavaFX so that more people are actively supporting/using it

Apache

Advantages

• Very experienced with open sourcing technologies
• Allow innovative features to be included reasonably quickly
• Has a good licence that is balanced between personal and commercial use
• Flexible with allowing outside contributions

Disadvantages

• Conflict of interest with Apache Pivot which makes the organisation unsuitable to handle JavaFX
• Apache have little interest in the mobile side since they are mainly focused towards web development
• Marketing of JavaFX will not be very strong

As long as Apache continue to support and develop Apache Pivot there will be a conflict of interest that will affect their handling of JavaFX. If Apache is to handle the open sourcing of JavaFX it must completely drop Pivot first. What is another major concern is the fact that Apache have not developed a real interest in the mobile side, which is one of the keys to growing JavaFX even further.


Oracle

Advantages

• Have a reasonable interest in the mobile side with the desire to expand further into this area
• Reasonable speed of getting innovating features and systems implemented in future JavaFX releases
• Can provide strong marketing and development support for JavaFX (including JavaFX mobile)

Disadvantages

• Little experience with open sourcing technologies
• Unreasonable and heavy handed licensing for JavaFX that may prevent it from being used on other devices (mobile side)
• Will be restrictive with allowing outside contributions

With the recent events surrounding Oracle suing Google over some possible patent infringements Oracle is not helping their reputation with the JavaFX community. If anything Oracle has made themselves completely unsuitable for managing the open sourcing of JavaFX, therefore it would be best for them to pass it on to a trustworthy organisation.


JCP

Advantages

• Flexible with handling licensing for technologies
• Reasonable experience with open sourcing technologies
• An independent organisation with no major conflicts of interest that would affect the handling of JavaFX

Disadvantages

• Known for limiting innovation (very slow speed for including innovations in a technology)
• Too much politics involved with companies (large sized) dictating what happens with a technology (not very community orientated)
• Does not handle marketing since it is left to the members to decide if they will do it for a technology or not

Lack of innovation is a real weakness of the organisation that will heavily hurt JavaFX if the JCP were to handle the technology. Also the politics that is involved in the organisation would completely leave the community out in the cold, which means that JavaFX would not receive the improvements it needs for its target markets and the JavaFX developers.


Foundation

Advantages

• Most independent of all the options
• Everyone can get involved with contributing to JavaFX
• JavaFX Mobile will receive the best development and support it needs since the foundation is only focused on JavaFX itself
• Lots of innovation occurring at a very fast pace for JavaFX
• Can provide open licensing that is balanced between commercial and personal use
• Decisions with developing JavaFX are made by the community (who can freely join as members), not by some large organisations
• Marketing will be effectively targeted to suit JavaFX since that is all the foundation is dealing with

Disadvantages

• Foundation will take a reasonable amount of time to be formed
• Unproven option that will need to earn the JavaFX communities trust

Clearly having a foundation setup would be the best option since it is completely independent, and it will only focus on JavaFX itself. However the organisation will take some time to be formed, and it will need to gain the trust of the JavaFX community if it is going to work effectively.

Moving JavaFX Forward

Recently some blog posts have been made questioning JavaFX's success and adoption. When it comes to this the JavaFX community is mixed with some saying that JavaFX has had reasonable success and adoption, while others are the direct opposite. It is all too easy to say that JavaFX has had no major successes when you only need to look around the corner to see the successes. Part of this reason is that some companies, and individuals are not publicly announcing that they have been using JavaFX, and what applications are using the technology. Also some of the community are not making a significant effort to see what companies and applications are using JavaFX.

While I can list some of the major applications that are using JavaFX I will not list all of them since the list is a big one that would take too long to go through. Many of these applications I have found to be innovative in their chosen field, and have been designed by actual designers, not software developers. Here are some of the major applications that use JavaFX:

• ThoughtSlinger (Word Processor)
• Indaba Music Console (Music Editor)
• TwentyOne (CRM)
• Timeshot (Photo Editor)
• Pirimap (Emergency Response History)
• MetaMaps (Diagram Editor)
• Ubivent Virtual Event (Event Hosting)
• WidgetFX (Desktop Widgets)

Here is a list of the major companies that have adopted the use of JavaFX in some of their applications (note that this is not a comprehensive list, it would take too long):

• Thoughtslinger Corporation
• IndabaMusic
• Ubivent
• Lodgon
• Canoo
• Oracle
• Exadel
• SWOffice

When it comes to the mobile area JavaFX has made very little progress. Not enough to make a significant difference against the RIA competitors. JavaFX's potential is largely untapped in this area. JavaFX has the potential to dominate in this area provided it is given the proper resources, and outsiders can contribute to improving the technology so it can be number 1. Open sourcing JavaFX would allow it to gain a foothold, especially with developing runtimes for some of the major mobile platforms (including Android), and making them freely available (without cost) to hardware vendors and users.

Deployment currently is the Achilles heel for JavaFX. Since JavaFX's first release it has been plagued with problematic loading times, and poor loading feedback for people using applications that utilise JavaFX, this is mostly problematic on the desktop side. Although the deployment situation is gradually improving much more still needs to be done in order to reach an acceptable level. When it comes to a rock and a hard place JavaFX is placed in a difficult situation where it can either wait for Java modularity to arrive, or develop a completely independent desktop runtime that does not rely on having the JRE present.

One blogger has commented that a good looking JavaFX application is solely determined by the technology itself, and that there are no good looking applications in the wild. Since this person is a User Interface Designer I am somewhat surprised that they would make a comment based on technology and not the people involved in the design. It really shows how much that person doesn't know about making good looking applications, what a great disappointment.

A good looking application is determined by the skill, and a little talent of the designer. In some cases the software developer / engineer acts as the designer, which is a very common situation and some have the rare ability to pull this off well. I have found plenty of JavaFX applications that are good looking. However the look of an application is a very subjective topic that greatly differs between people.

Designers don't need to use a specialised design tool in order for graphics to be used in a RIA technology. JavaFX already has integration via plugins with some of the major graphics design tools (Inkscape and Photoshop). At the moment the JavaFX Authoring tool is under development, and although Oracle is running a bit on the late side with development it will be worth it when it is released, “good things take time”.

There are two videos that showcase just how innovative the tool really is. If it was out today it would provide a major advantage for using JavaFX against the other RIA competitors. Oracle really need to provide regular communication on how the Authoring tool is progressing, which is sorely lacking. I can understand why some of the community are a bit worried about this.

Although JavaFX is lacking in a wide range of quality controls with each release more and more controls are being added. Increasing the number of built-in controls is the best way to go, as opposed to having third party control providers. Built-in controls provide consistent quality that software developers can rely on. Remember that JavaFX unlike Swing is designed for creating consumer applications where custom controls may be created on the fly.

As such it is absolutely pointless to compare Swing and JavaFX, only contrasting can be done between them. Regardless of which front-end technology is used it will not be possible to satisfy every situation where it is used, hence third party controls are used or custom ones are created.

Plenty of major real world JavaFX applications have their own custom controls created entirely using JavaFX. Oracle should look at incorporating some of these controls in future JavaFX releases. Why do we need to look at Swing when there are plenty of JavaFX applications that provide the missing controls? We have lots of inspiration to look at in the JavaFX camp with the work that is done using JavaFX. Oracle should seize on this to further improve JavaFX!

With each release JavaFX has gone from strength to strength, and proven critics wrong time and time again. What JavaFX needs to do in order to improve is to continue making solid improvements, make deployment faster and easier, have mobile runtimes for some of the major mobile platforms, and provide provide low level graphics and media manipulation APIs.

Right now JavaFX is at a crossroads with its reasonable level of success and adoption. In order for JavaFX to move forward further it must be FULLY open sourced in order to reach greater success and adoption, and to gain a solid foothold in the mobile area.