Note 1: I am following Jim Weaver’s lead, since he discovered JavaFX 1.2 is downloadable from javafx.com. Enjoy the new release!

Note 2: I have updated the section below on nativearray.  Please use with caution!

The JavaFX 1.2 release is a huge upgrade from 1.1, both in terms of functionality and API improvements.  This means there are lots of cool new things to take advantage of, but at the same time you will spend quite a lot of time migrating your applications.

Fortunately, after upgrading JFXtras, WidgetFX, and dozens of sample applications for the Pro JavaFX Platform book, I have this all down to a science.  In the rest of this blog I will take you through a whirlwind tour of the relevant new features, and most common migration hurdles so you can be up and running in record time!

First the fun stuff…  new features.  Here are the top 10 features you should start using today:

JavaFX Top 10 Features (revised)

1. Skinnable UI Controls

It is great to have some pure JavaFX controls, such as Button, ListView, ProgressBar, and Slider that don’t rely on Swing peers underneath.  An added advantage is that they are fully skinnable to match the fonts and color palette of your application.

2. New Layout Classes

The new layout classes including Tile, Stack, Flow, ClipView, and Panel are a very welcome addition!  The layout API has also gotten a lot cleaner, which makes it easier to write your own layouts, such as the JFXtras Grid.

3. Charting Support: Area, Bar, Bubble, Line, Pie, Scatter, X/Y

Now I can compete with my Flex buddies on business oriented RIAs!  The new charting and graphing support is a must for any enterprise applications, so I am glad to see it made the cut.

4. RSS/Atom Feed Support

Having built-in RSS/Atom feed support is a welcome addition, and will make it much easier to write feed-based applications that cleanly port from the desktop to mobile.

5. Local Data Storage

An easy way to save state between sessions, no Web Start API hacking required!  See the new Resource and Storage classes in the javafx.io package for details.

6. Stage Infrastructure: Screen and Alerts

There is some new functionality that makes it easy to pop-up alert dialogs, or work directly with the screen bounds.  While you could have done direct Swing/Java2D hacks before, this helps keep your code mobile safe.

7. Improved Asynchronous Processing Model

The new Task class supercedes the AsynchronousAbstractOperation with a clean API for calling long-running tasks.  The code running in the background has to be coded in Java, but if you are looking for a JavaFX alternative see the JFXWorker (which is part of the JFXtras project).

8. BoxBlur effect

Finally, a high-performance alternative to Gaussian blur.  This is now the default for DropShadow, which should speed up a lot of applications!

9. Math and Properties Classes

There are new JavaFX equivalents for java.lang.Math and java.util.Properties in the javafx.util package.  Make sure you use these instead so your application is portable to mobile.

10. High Performance Referencing of Java Arrays (updated!)

Java arrays are now optimized so that they can be used directly from JavaFX code without conversion to a sequence.  This can have a huge performance gain in programs transfering large models between Java and JavaFX code, and is transparent to the application developer.

Note: There is experimental support for direct creation of Java arrays in JavaFX using the nativearray keyword.  Use with caution, because this functionality may be removed at any time.

 Now that you are incentivized to upgrade, it is time to figure out how to migrate your existing applications.

The Definitive 1.2 Migration Guide

If you have made it this far, you are a serious JavaFX hacker!  This section covers the most common language, functionality, and API changes that you will encounter when migrating applications from JavaFX 1.1.  If you notice anything that is not covered, feel free to add it in the comments and I will update the guide as appropriate.

General:

• JavaFX 1.2 is not binary compatible – If you use any jars or third-party JavaFX libraries (such as JFXtras), they must be recompiled for the new release or you will get compilation errors.  Speaking of JFXtras, a new version which has been updated for JavaFX 1.2 is nearly ready, and will be announced here when it is complete!
• All internal-only APIs are broken – More details broken out by section below, but if you rely on any impl_ or com.sun packages, your code will definitely need to be updated.
• Linux and Solaris are now supported – This is more of a feature than a migration issue, but if you have users on multiple platforms you can now proudly state that Linux is supported.

Language Changes:

• No more variable shadowing in nested blocks – It previously was valid to name a variable the same in both the inner and outer block of an expression.  The variable in the inner block would simply replace the one in the outer.  However, this will throw a compiler error in JavaFX 1.2.  The fix is simple…  just use a different variable name.
• Use Mixins instead of Multiple Inheritance – JavaFX no longer supports multiple inheritance.  Instead you can extend one class and as many mixins as you like.  Mixins are like interfaces in Java, except they can have variables and implementations that are shared by all the classes that extend them.  The only change you have to make in your application to start using mixins is to add the mixin keyword when you define a new class like this:

public mixin class Resizable { /* variables and functions here */ }

• Commas are required in sequences – Sequences now require commas between elements (except those that end in braces).  This is a little less convenient, but actually a very good thing, because it avoids several language pitfalls that were hard to track down before.

Node Changes:

• Node.boundsInScene is gone – This was removed for performance reasons, fortunately there is an easy replacement that offers the same functionality:

node.localToScene(node.boundsInLocal)

• Node.focusable -> Node.focusTraversable – Small API change, but good to know when you get the compilation error on focusable not found.  This is part of a larger focus fix where any Node that is visible, focusTraversable, and not disabled will be eligible for focus (a key listener is no longer required).
• CustomNode.create() gets called before init – Previously the CustomNode create() method would get called after init and before postinit.  Now that it gets called even earlier than init, some of your code may not work correctly.  Make sure that any variables you are depending upon in the create() method are either initialized inline or have a bind declaration so they get updated once set.
• SwingControl.enabled -> Node.disable – There is a new disable flag on the Node class that is used universally across all controls to enable or disable them.  This conflicted with the old SwingControl.enabled variable, which has now been removed.
• Rectangle2D -> Bounds – All references to Rectangle2D have been changed to the new javafx.geometry.Bounds class, which may have a ripple effect through your code.

Layout Changes:

• min/max/pref -> getters – All of the Resizable methods (minimumWidth, minimumHeight, maximumWidth, maximumHeight, preferredWidth, preferredHeight) have been replace with function getters (getMinWidth, getMinHeight, getMaxWidth, getMaxHeight, getPrefWidth, getPrefHeight respectively).  The prefWidth/Height functions take an extra parameter, which is the amount of space in the opposite dimension.  This is very useful for doing height or width constrained layouts, such as Flows, but can be ignored by passing -1.
• impl_layoutX/Y -> layoutX/Y – The impl_layoutX and impl_layoutY methods have been replaced with official layoutX and layoutY variables.  It is recommended that you use these variables over translateX/Y if you are moving nodes into position.
• impl_requestLayout() -> requestLayout() – The requestLayout function has similarly moved from an internal to a public API.
• impl_layout -> doLayout() – Rather than having a function to set the layout on, you now override Parent.doLayout().
• Panel class added for declarative layouts – If you are looking for a functional alternative to Container, take a look at the new Panel class, which lets you set the layout declaratively.  It also has variables to override the default min/max/pref values without subclassing Container.
• New functions on Container to help with layouts – There are a whole slew of new functions on the Container class that make it easier to work with the new layout system.  Make sure to read through them, because they will both save you time and help you follow the best practices for layout design.
• Different transformation order – Previously the transforms[] variable allowed you to apply transformations included in the layoutBounds, while scaleX/translateX/rotate etc. were applied after layout.  Now both transforms[] and the transformation variables are calculated after layout uniformly.

Skin/Control Changes:

• Skin.scene -> Skin.node – The name of the Node on Skin has changed from scene to node, which helps reduce confusion with the Scene class.
• Skin.compute* methods removed – There were a series of computePreferredWidth/Height/etc. methods that were removed.  Instead you can directly use the getPrefWidth/Height/etc. methods on the Resizable class mentioned above.
• Skin is now abstract – The Skin class is now abstract, and required that you implement your own contains and intersects methods.  You can either do this by using the new JFXtras AbstractSkin class or using the following boilerplate code:

override function contains(localX:Number, localY:Number):Boolean {
    return node.contains(localX, localY);
}

override function intersects(localX:Number, localY:Number, localWidth:Number, localHeight:Number):Boolean {
    return node.intersects(localX, localY, localWidth, localHeight);
}

• New Behavior class – There is a new Behavior class that is meant to be used together with Control and Skin to provide reusable behaviors.
• TextBox.text -> rawText, TextBox.value -> text – There was some swizzling of variables on the TextBox class.  What used to be text changed to rawText, and value now has the same semantics text used to have.

Asynchronous Changes:

• RemoteTextDocument has been removed – Use HttpRequest directly instead.
• AbstractAsyncOperation has been removed – Use the new Task infrastructure instead for communcating with Java code running in a background thread.

Animation Changes:

• Transition.interpolate -> Transition.interpolator – A small name change to make room for a new interpolate flag that allows you to turn on or off interpolation altogether.
• Transition now extends Timeline - This is a welcome change, which makes it much easier to work with Transitions and Timelines together.  To support this change ParallelTransition and SequentialTransition now take a sequence of Timeliens.

Java Equivalent Functions:

• java.lang.Math -> javafx.util.Math – There is a new JavaFX math library, which is a drop-in replacement for the Java math library.  The main advantage of using the new JavaFX math library is that all functions are supported on mobile devices (including pow, log, etc.).
• java.lang.Properties -> javafx.util.Properties – Another class that is similar in functionality to the Java equivalent, but portable to mobile.  Be warned, however, that the JavaFX properties file format is not the same as the standard Java properties file format.

CSS Changes:

• CSS Update Defect (RT-4817) – Stylesheet updates no longer affect newly added Nodes due to a known defect.  In the meantime, you can do this to force a stylesheet refresh:

def senators = bind model.senators on replace {
    delete sceneRef.stylesheets;
    sceneRef.stylesheets = "{__DIR__}styles.css";
}

• CheckBoxSkin.textFill doesn’t accept styles (RT-4819) - The check mark will pick up the style you set, but the text won’t.  The workaround for now is to create a checkbox with empty text and add a text node beside it with the correct styling and event handlers.
• Can’t update the skin property of Control from CSS (RT-4820) – Another bug in the skin support.  You can set this in code instead for now.

Production Suite:

• UiStub -> FXDNode – UiStub has been replaced with FXDNode, which includes some extra functionality, such as backgroundLoading, and placeholder images.

Miscellaneous:

• Image.fromBufferedImage() removed – This has moved to SwingUtils.toFXImage().  Remember that if you use this function it will limit portability to mobile devices.
• Color.fromAWTColor() removed – Yet another AWT-ism that has been removed. The JavaFX Color class is pretty thorough, so there shouldn’t be any reason to work with AWT Colors.
• Duration.toDate is gone – As far as I know there is no equivalent functionality, but you can always get a duration’s value as a long and manipulate it directly.
• Different variable names for the Affine class – If you use the Affine class, then your code is likely to break due to the new, more descriptive, method names, but the functionality is the same.

Whew!  …that was quite a lot to take in.  If you are interested to read more about the JavaFX 1.2 release including the new controls, layouts, and other functionality, the best source is to checkout the Pro JavaFX book that Jim, Dean, Weiqi, and I are writing.  It is almost fully updated for the JavaFX 1.2 release, and is available in Alpha right now from the book website.

I want to give a special thanks to Richard Bair and Amy Fowler from the Sun JavaFX team for providing a lot of valuable information on the JavaFX 1.2 release along the way.

Happy hacking on JavaFX 1.2!

Now that the JavaFX 1.0 Release is out, it is time to dust off all your old JavaFX code and fire it up, right?  Well, not quite…  There were a whole lot of changes in the span of a few months, and it is guaranteed that your program will need a little TLC before it runs.  Fortunately, I’ve already gone through this pain on a relatively large codebase (WidgetFX), and can share what I learned.

Language Changes

• Change “attribute” to “var”/”def” – There is no more attribute keyword, but it is a simple search and replace to change it to var everywhere.  On a second pass you might want to convert vars that are never changed to def for efficiency.
• No More “static” – If you want to make a variable or function as static, just move it outside your class declaration.  If it is declared public you can access it from anywhere else just by prefacing it with the file name, no static modifier needed.
• New Access Modifiers – The default access modifier was changed to private rather than package, so you need to change any attributes or functions that had no modifier to package and then can delete all references to private.  On a second pass it may be a good idea to button-up permissions by using the new public-init and public-read permissions.  Here is a quick-reference table:
  

  Preview	1.0	Migration
  private	default	Remove this keyword everywhere
  default	package	Add package anywhere no modifier was specified
  protected	protected	No change
  public	public	No change
  N/A	public-init	Use this anywhere the user should be able to initialize and read, but not update
  N/A	public-read	Use this anywhere the user should be able to read, but not initialize or update

• Required “override” – It is now mandatory that you use the override keyword on any member variable or function that exists in the superclass.  Expect to be going through lots of compiler errors to find all the places you need to fix this…
• {} Instead of “+” for Concatenating Strings – While the java-esque “+” operator for concatenating strings was an easy habit to fall into, it is no longer valid.  Instead you have to use the {} syntax to build strings.  For example, rather than “hungry for: ” + meat, you would write “hungry for: {meat}”.
• Keyframe Syntax – While this is not required to get your code working, there is a new KeyFrame syntax for doing animation that has the potential to make your code much shorter.  Rather than creating an instance of the KeyFrame class you can simply write “at (duration) {x => y}”.

On Applications, Stages, Scenes, and Nodes

All your previous conceptions of what the terms application, stage, and scene meant have now been blown away.  For those of us who got very wired in to the old terminology, here is a quick reference from the old to the new:

Note that you can return a Stage, Scene, or Node from your main class and they will all work within an execution context (such as an Applet).

Some things to note:

• How do I size my window? – If you want to set the outer bounds of the window, you can use the Stage width and height.  Just remember that the window decoration will reduce the content area left.  You can also set the Scene width and height, which will correctly size the window for the contents (including decorations).  Unfortunately you can only do this once, because they are public-init variables.
• Accessing the Window – For some advanced functionality you may need to get direct access to the java.awt.Window instance underlying a Stage.  This has been taken out of the API, but I put together a utility class in JFXtras called WindowHelper that works around this issue.
  • Note: if there is anything you need to do directly on a Window class, raise it to the JavaFX team so they can make sure it gets added in a future release.

Where did my class go?

There were a lot of package name changes, and while you can probably dig around in the API docs and find most of what you want, it is good to have an idea about the main changes.

Here is a quick package migration guide:

API Changes

There are way too many API changes to hit everything, but here are a few that are common or relatively hard to track down:

Swing changes:

• Swing classes extend Node, no need for ComponentView
• All the Swing class names have “Swing” appended in front (e.g. Slider is now SwingSlider)
• No more containers or layouts (see the omissions section below)
• Wrapping a Swing component is now accomplished via SwingComponent.wrap()

Graphics:

• Horizontal/VerticalAlignment are gone, use a translation with a bind expression instead
• FontStyle is gone and replace by properties on the Font class
• Number is used almost everywhere now rather than Integer

Animation:

• The start() method has been renamed to play()
• autoReverse vs. rate – Previously, the only way to reverse an animation on subsequent runs was to set autoReverse to true.  Now you can (and have to) use rate to control the direction of the animation by setting it to 1 for forward and -1 for backward.

Getters replaced by vars:

• MouseEvent.getButton() -> MouseEvent.button
• MouseEvent.getStageX() -> MouseEvent.sceneX
• Node.getWidth() -> Node.boundsInLocal.width
• etc.

Miscellaneous:

• __ARG__ -> FX.getArguments()
• System.out.println -> println() (builtin)
• System.exit(0) -> FX.exit()
• DeferredTask -> FX.deferAction()

Some noticable omissions include:

• Dialogs – SwingDialog is gone and there is no equivalent yet.  Fortunately, I did the hard work and hacked a Dialog replacement (that extends Stage) which you can get as part of the JFXtras project.  It includes support for parent windows, modality, alwaysOnTop, and even auto-size via a “pack” option.
• Layout – ClusterPanel and the rest of the Swing containers are gone.  The only layout classes that ship as a part of the 1.0 release are HBox and VBox, which are useful, but not nearly enough.  Until they release some official layouts, there is a Node-based Grid layout implementation in the JFXtras project.

New and Noteworthy

• Reflection – The new JavaFX reflection APIs are very powerful.  They are not for the faint of heart, and have minimal documentation, so this may be a good future blog item.
• CSS Styling – The new CSS styling support will help bridge the gap between designers and coders.  Same comment about lack of documentation, but it is fairly intuitive once you start using it.
• Transitions – There is a whole new transitions package that makes it even easier to do common animations.  Give it a try!

In Summary

I still have nightmares about painstakingly going through thousands of compilation errors in my code.  Just when I thought I had caught the last one, another few files started compiling and I was buried all over again.  Hopefully through my trial-and-error you will save a few sleepless nights.

Did I catch everything?  Hell no!  But this should be enough help you to get over that initial adoption hump.

Good luck!