The JavaFX 1.3 SDK is an important update to the JavaFX 1.2 SDK. Most applications will need little or no modification to compile and run on JavaFX 1.3, but there are a few incompatible changes that application developers may need to be aware of. For a higher-level description of new features and enhancements introduced in this release, see What's New in JavaFX 1.3. For a tutorial on using the JavaFX 1.3 UI controls, see Using JavaFX UI Controls.

Migrating Existing Applications to JavaFX 1.3

This section describes the issues that an application developer may face when migrating from JavaFX 1.2 to JavaFX 1.3. It consists of compiler changes, API changes, semantic changes, and additional migration tips. Immediately following each description is a paragraph beginning with the text "Source Change Needed." These paragraphs provide specific suggestions for migrating an application's source code to JavaFX 1.3.

Compiler Changes

The following compiler changes may cause application developers to modify their source code. For a complete list of compiler changes, see the Compiler and Language Changes (Full Details).

JavaFX 1.3 is not binary-compatible with JavaFX 1.2

Class files produced by the JavaFX 1.2 SDK will not run directly on JavaFX 1.3. All JavaFX Script source files need to be recompiled with the JavaFX 1.3 SDK.

Source Change Needed: None

Some forward references now get errors instead of warnings

In JavaFX 1.2, most forward references caused compiler warnings. However, the value used for such a forward reference was the default value of the type of the referenced variable, not that variable's initial value. Using such a forward reference could lead to unpredictable behavior, so the JavaFX 1.3 compiler generates an error instead of a warning.

For example:

var x = y;
var y = 10;
println("{x}");

will cause the following error to be generated:

Sample.fx:1: Illegal forward reference: variable y is not initialized.
var x = y;
 ^
1 error


Source Change Needed: Eliminate any forward references that cause errors, either by reordering the variable declarations, or by separating the variable declarations from their assignments.

Side effects are no longer allowed in bind expressions

In JavaFX 1.2, it was possible to bind to an expression with a side effect, such as assigning a value to an instance variable. In JavaFX 1.3, bind expressions are evaluated lazily, so there is no guarantee how often or when a bind expression will be evaluated. Allowing side effects would lead to unpredictable behavior, so they are no longer allowed.

Here is an example of a bind which has a side effect:

var yy: Integer;
var zz = 10;
var xx = bind { yy = zz }; // yy = will get an error in JavaFX 1.3
println("xx={xx}, yy={yy}");
zz = 89;
println("yy={yy}");


The side effect of the bind is that yy is set to the value of zz. In JavaFX 1.2, this code compiles and executes without problem. In JavaFX 1.3, the compiler generates an error message:

Sample.fx:3: Not allowed in bind context =
var xx = bind { yy = zz };
^
1 error


Source Change Needed: Place any necessary side effects in an "on replace" trigger rather than in the bind expression itself.

Binds can be lazy if there is no associated on replace clause

In JavaFX 1.2.3, binds are "eager." When a variable in the bind expression changes value, the bind expression is computed and the resulting value is stored into the binder variable. Now that side effects are no longer allowed in binds, this change will not be noticeable to an application.

Source Change Needed: None, other than avoiding side effects as previously described.

API Changes

Most enhancements to the JavaFX API are simple additions of new classes, or new variables and functions in existing classes. A few incompatible API changes were made in JavaFX 1.3 that may require changes to an application's source code, either because the API call itself has been altered in some way, or because the semantics have changed in an incompatible manner. The following items describe the incompatible changes, plus any source code changes that may be needed to react to them.

Modified or Removed Variables and Functions

• The following variables each had an access modifier of public in JavaFX 1.2.3, meaning that an application could write to any of these variables at any time. They were not intended to be writable variables, however, and modifying them had no meaningful effect. The access modifiers have now been changed to reflect the correct usage of these variables:
  
  public-read: AppletStageExtension.appletDragSupported
public-read: MediaError.cause, MediaError.message
public-read: MediaPlayer.currentCount
public-init: Media.source
  
  

  Source Change Needed: Few, if any, applications should be affected by this change. The solution is to remove the code that was previously writing to these variables. In the case of Media.source, you should now initialize the source variable when creating a Media object, for example:

  Media { 
      source: "urlstring" 
  }
  
  

• Type change for Slider.minorTickCount
  
  

  In previous releases, the minorTickCount variable of the Slider class was declared as Number. Since it does not make sense to have, for example, 2.5 minor ticks between two major ticks, this variable's type has now been changed to Integer.
  
  Source Change Needed: Most applications will need no changes. If you use the minorTickCount variable in arithmetic expressions, casting minorTickCount to Number may be required if non-integer arithmetic is needed. Conversely, you may now see a "possible loss of precision" warning when assigning a numerical expression to the minorTickCount variable. This warning may be safely ignored, or the resulting expression may be cast to Integer prior to assignment to avoid the warning.

• Container and Control now extend Parent directly
  
  

  The Container and Control classes now each extend Parent instead of Group and CustomNode, respectively. This provides more freedom in establishing the relationship between content and children, and puts all three base parent types (Group, Container, CustomNode) on the same level, cleaning up the layout API and enabling each to evolve independently without affecting the others.
  
  Source Change Needed: None needed for Container, unless you were casting a Container to Group, or setting its groupBlend variable. Application developers should remove such usage from their programs. None needed for Control, unless you were trying to subclass and create a custom control by overriding the create() function of CustomNode. Such usage would not have worked anyway and should be removed.

• Removal of doLayout() function from Group
  
  

  In JavaFX 1.2, Container extended Group and both classes exposed a doLayout() callback function to perform layout of content during the layout pass. In JavaFX 1.3, Container now extends Parent directly, becoming the definitive layout base class, providing the doLayout() function to be overridden by subclasses. Group no longer has doLayout().
  
  Source Change Needed: Existing code which subclasses Group and overrides doLayout() should now extend Container instead.

• Chart, Legend, and Axis now extend Parent directly
  
  The Chart, Legend, and Axis classes now each extend Parent instead of CustomNode. This provides more freedom in establishing the relationship between content and children. Additionally, the type of protected var Chart.chartContent has changed from Container to Node, and the type of protected var XYChart.plot has changed from Panel to Container.
  
  Source Change Needed: None, unless an application creates a custom subclass of Chart, Legend, or Axis, which isn't a common use case (and likely didn't work in JavaFX 1.2). If such a subclass does exist, and currently overrides the create() function of CustomNode, you will need to remove this usage.
  


• ToggleGroup now uses Toggle mixin.
  
  

  Previously, ToggleGroup worked exclusively with ToggleButton objects. In this release, ToggleGroup also works with RadioMenuItem objects. A Toggle mixin class has therefore been created.
  
  With this change, the following line:
  
  public-read package var buttons:ToggleButton[];
  
  becomes:
  
  public-read package var toggles:Toggle[];
  
  and this line:
  
  public var selectedButton:ToggleButton;
  
  becomes:
  
  public var selected:Toggle;
  
  Source Change Needed: Application developers can simply change the usage of the variable names and types to match the new API.

• Removal of the following protected functions.
  
  protected function Flow.computeDimension()
protected function Container.initSize()
  
  

  Source Change Needed: These functions are no longer needed. Application developers may safely remove these functions from any class that extends Flow or Container.

• Removal of boolean variable Text.overline
  
  

  While underline and strikethrough are both commonly used in typography, there is little precedent for overline. Removal of this feature helps improve performance, and simplifies text-handling code. Unlike strikethrough and underline which are sometimes supported in the font, overline is not. This variable has therefore been removed from the Text class.
  
  Source Change Needed: Remove any usage of this variable.

• Promotion of managed variable from LayoutInfoBase to Node
  
  

  The managed variable has been moved from LayoutInfoBase to Node.
  
  Source Change Needed: Application developers that wish to make a node unmanaged should set managed=false directly on Node instead of in a LayoutInfo used by that Node.

• Variable name changes in javafx.scene.chart.Chart
  
  

  The previous release contained typos in some Chart variable names. The following variables have therefore been renamed:
  
  chartBackgoundFill is now chartBackgroundFill
chartBackgoundStroke is now chartBackgroundStroke
chartBackgoundStrokeWidth is now chartBackgroundStrokeWidth.
  
  Source Change Needed: Change the spelling of the names as shown.

Semantic Changes

• Preferred size for Flow and Tile
  
  

  The Flow and Tile classes previously contained buggy algorithms for computing their preferred sizes. The Tile class now computes its preferred width and height based on the rows variable (for horizontal) and columns variable (for vertical). The rows and columns no longer reflect the actual number of displayed rows and columns that could change if a Tile object is resized to something other than its preferred size. In addition, the Flow class now has a wrapLength variable that controls the preferred width (horizontal) or height (vertical).
  
  Source Change Needed: Few, if any, applications should need any modification.
  

• Containers and Controls no longer initialize their sizes in postinit
  
  

  In previous releases, the Container and Control classes all initialized their width and height variables to their preferred sizes. This is no longer the case in JavaFX 1.3, since CSS styling now plays a vital role in what the preferred size of a Control should be, and CSS is not initialized until the Control is added to a Scene and the first pulse occurs.
  
  Source Change Needed: Few, if any applications should need any modification.

• Groups now auto-size Resizable nodes
  
  

  In previous releases, controls that were not placed in a layout container were not automatically resized. In JavaFX 1.3, all Parent classes (Group, Container, and CustomNode) will automatically resize any managed Resizable children to their preferred size. Controls will now be properly resized regardless of where they are placed in the scene graph. With this change, it becomes imperative that all Resizable nodes return appropriate values from getPrefWidth() and getPrefHeight(), since the Parent node will use the values returned by those functions to determine the size to give the resizable node during layout. If getPrefWidth() or getPrefHeight() erroneously return 0, then the node will not be visible, because it will be resized to 0 x 0.
  
  Source Change Needed: Most application developers will want the new default behavior in JavaFX 1.3. If automatic resizing is not desired for a particular Group node, you may set Group.autoSizeChildren = false to restore the JavaFX 1.2.3 behavior.

• Containers and Controls now have default grow, shrink, and fill behaviors
  
  

  In JavaFX 1.2, Resizable nodes could only express their minimum, preferred, and maximum size preferences. If Containers were allocated more or less space than their preferred sizes, they used their own policy for determining how to distribute that differential space. HBox, VBox, and Flow always resized children to their preferred sizes, regardless of how much space existed. Stack and Tile would automatically expand children beyond their preferred sizes to fill their layout space. In JavaFX 1.3, grow, shrink, and fill preferences have been added to Resizable so that the Container classes can make resizing decisions based on their type of content rather than using its own policy which may not make sense for the content.
  
  Most Controls (Button, Label, etc.) return grow and shrink preferences of NEVER, and a fill preference of false. This means that when placed inside containers that have extra space, these controls will not be resized beyond their preferred sizes to take up that additional space. For example, if a Button were placed inside a Stack in JavaFX 1.2, it would be resized to fill the Stack (which might be large, depending on its content); however, in JavaFX 1.3, the Stack will honor the Button's no-grow preference and keep it to its preferred size, regardless of how big the Stack is, which is usually the desired outcome for a Button.
  
  Some Controls (ListView, ScrollView) and all Containers return grow and shrink preferences of SOMETIMES, which means that when placed inside Containers with extra space, they will be resized beyond their preferred sizes to take their share of extra space (provided no other children in the container have a grow preference of ALWAYS, which has a higher priority). This is a change from JavaFX 1.2, where containers placed inside other containers would grow only if the parent container were a Stack or Tile; otherwise, they were kept to their preferred size, even though their parent had more room.
  
  Source Change Needed: Most application developers will want the new default behavior. Applications that depend on the JavaFX 1.2 behavior may now see that containers (HBox, VBox, etc.) are suddenly growing in size as the overall scene is resized, when they previously were kept to their preferred size. If the old behavior is desired, an you can use LayoutInfo to override the grow/shrink/fill preferences.

  For example:
  

  def NO_GROW = LayoutInfo { hgrow: Priority.NEVER vgrow: Priority.NEVER };
  
  VBox {
      // ensure VBox tracks size of scene when user resizes stage
      width: bind scene.width
      height: bind scene.height
      content: [
          HBox { layoutInfo: NO_GROW ... }
          ListView { layoutInfo: NO_GROW ... }
          ...
      ]
  }
  

  
  
• Support added for vertical filling in HBox and horizontal filling in VBox
  
  

  With the addition of the growing/filling layout behavior in JavaFX 1.3, it became necessary to enable an HBox to set the height of each child's layout area to the HBox's actual height (rather than the height of the tallest child) and a VBox to set the width of each child's layout area to the VBox's actual width (rather than the width of the widest child). To control this behavior, HBox has a new fillHeight:Boolean variable and VBox has a new fillWidth:Boolean variable, both of which default to true, since this turns out to be the more commonly desired layout behavior. In addition, the variable vfill (of class HBox) has been renamed fillHeight, and the variable hfill (of class VBox) has been renamed fillWidth.
  
  Source Change Needed: If an application depends on the older behavior where the layout areas are limited to the height of the tallest child (HBox) or width of the widest child (VBox), even when there is more space in the container, then it can set the variable to false:
  
  HBox { fillHeight: false }
VBox { fillWidth: false }

• Focus traversal mechanism change
  
  

  In previous releases, the behavior of the focus traversal mechanism was to "steal" certain keystrokes, such as TAB and shift-TAB. Pressing TAB or shift-TAB would cause focus traversal to occur instead of a key event being delivered to the focused node. That mechanism has been removed: all keystrokes are now always delivered to the focused node. Nodes that process key events and subsequently move the focus should call Node.requestFocus() in response to the appropriate event.
  
  Source Change Needed: Few, if any, applications should require focus traversal on their own scene graph nodes. Applications that do need this feature must explicitly call Node.requestFocus() when the appropriate key is pressed.
  

• Animation: Changed semantics of KeyValue evaluation
  
  

  In previous releases, the value that Timeline used for keyValue was updated dynamically. That is, on every pulse it would query for the current value of keyValue on every interpolate() call. This allowed keyValue to change at any time, from anywhere. However, this behavior came at the expense of performance, and was wasteful in the majority of cases.

  In this release, all KeyValues are evaluated once before the Timeline object plays for the first time. KeyValues retain this value until an explicit request for reevaluation.

  A new function, Timeline.evaluateKeyValues() has also been added. When called, all KeyValues in the Timeline are reevaluated.

  Source Change Needed: Applications that need their KeyValues to be evaluated between successive runs of a Timeline will need to add a call to Timeline.evaluateKeyValues() before calling playFromStart() or play().

Additional Migration Tips

CSS

In JavaFX 1.2, the CSS properties used the same names as those in the WC3 CSS specification, even though they did not fully implement the specification. W3C provides a convention for vendor-specific extensions, which JavaFX now uses. All CSS properties in JavaFX are now prefixed with "-fx-", for example, "-fx-font-size", which specifies the size of the font to use in a CSS declaration.

Setting the Size of Nodes

To set the size of a node in JavaFX 1.3, you can set the node's layoutInfo variable:

JavaFX 1.2

var searchBox = VBox {
    content: [
        Label {
            height: 20
            ...
        }
        ...
    ]
}

JavaFX 1.3

var searchBox = VBox {
    content: [
        Label {
            layoutInfo: LayoutInfo { height: 20 }
            ...
        }
        ...
    ]
}

Alternatively, you can make the node unmanaged by setting managed to false.

Media Files

Media files can no longer be loaded directly from .jar files. See JavaFX FAQ Section 5.3 for more information.

Establishment of control width and height

In previous releases, a control's width and height was established immediately when the control was created. In JavaFX 1.3, the width and height are established asynchronously, when the first layout pass is done. If code relied on a control's width and height to be established early (for example, using those values to compute layoutX during initialization), this code will no longer work in JavaFX 1.3. Remedies are to use bind, or to use width and height during the layout pass, as in the onLayout function of a Panel.

Additional Features in JavaFX 1.3

This section describes the new JavaFX 1.3 features that an application developer may wish to use. It contains additional information about the compiler and language changes, plus descriptions of the API enhancements introduced in this release.

Compiler and Language Changes (Full Details)

JavaFX 1.3 is not binary-compatible with JavaFX 1.2

Class files produced by the JavaFX 1.2 SDK will not run directly on JavaFX 1.3. All JavaFX Script source files need to be recompiled with the JavaFX 1.3 SDK.

Some forward references now get errors instead of warnings

In JavaFX 1.2.3, most forward references caused compiler warnings. However, the value used for such a forward reference was the default value of the type of the referenced variable, not that variable's initial value. Using such a forward reference could lead to unpredictable behavior, so the JavaFX 1.3 compiler generates an error instead of a warning.

For example, in JavaFX 1.2 this code:

var x = y;
var y = 10;
println("{x}");

will get a warning on line 1, and will print 0, which is not what was intended.

In JavaFX 1.3, an error will be generated:

Sample.fx:1: Illegal forward reference: variable y is not initialized.
var x = y;
 ^
1 error

You can avoid this error while preserving the same semantics as in JavaFX 1.2.3 by removing the initializer and adding the correct type, for example:

var x:Integer;
var y = 10;
println("{x}");

This code will cause x to be initialized with the default value for type Integer, which is the same behavior as in JavaFX 1.2.3. However, if you want to initialize x with the initial value of y, then the code should be reordered so that y is declared first:

var y = 10; // reorder the variables
var x = y;
println("{x}");

There are various other contexts in which a forward reference will not cause an error message because there are some circumstances in which the program will behave as expected. The following option will cause the compiler to generate warning messages on these forward references:

-XDfwdRefOpt="objlit|bind|interpolate|keyframe|lambda|assign|onreplace|oninvalidate"

Any subset of the list of keywords can be used, for example,

-XDfwdRefOpt="bind|onreplace". This is an unsupported option which is subject to change.

Side effects are no longer allowed in bind expressions

In JavaFX 1.2, an application could bind to an expression with a side effect, such as assigning a value to an instance variable. In JavaFX 1.3, bind expressions are evaluated lazily, so there is no guarantee how often or when a bind expression will be evaluated. Allowing side effects would lead to unpredictable behavior, so they are no longer allowed.

Here is an example of a bind which has a side effect:

var yy: Integer;
var zz = 10;
var xx = bind { yy = zz }; // yy = will get an error in JavaFX 1.3
println("xx={xx}, yy={yy}");
zz = 89;
println("yy={yy}");

The side effect of the bind is that yy is set to the value of zz. In JavaFX 1.2.3, this code compiles and executes without problems. In JavaFX 1.3, the compiler generates an error message:

Sample.fx:3: Not allowed in bind context =
var xx = bind { yy = zz };
 ^
1 error

Binds can be lazy if there is no associated on replace clause

In JavaFX 1.2.3, binds are "eager." When a variable in the bind expression changes value, the bind expression is computed and the resulting value is stored into the binder variable.

For example:

var xx = bind fred(zz);

when zz changes value, fred(zz) is called and the returned value is stored into xx.

In JavaFX 1.3, binds can be lazy. This means that the compiler is free to optimize the generated code to delay the computing of the new value of the bind expression, and the storing of that value into the binder variable, until the binder variable is actually referenced. In the previous example, if zz is modified from 1 to 1000 in a for loop before xx is referenced, the result in JavaFX 1.2.3 is that fred(zz) is called 1000 times, while in JavaFX 1.3, fred need not be called at all until xx is referenced. Then a single call - fred(1000) can be performed and the result stored into xx.

Allowing for lazy binding makes the computing of a bind expression somewhat non deterministic: it doesn't have to happen at a particular point in the execution of the program, and doesn't have to happen at all in some cases. This is why side effects are no longer allowed in bind expressions - you can't count on when, or even if, the side effects will actually occur.

An on replace clause on a declaration with a bind acts like an implicit reference to the binder variable. This forces the bind, and other binds upon which it depends, to be eager.

For example:

var x1: Number;
var x2 = bind x1 * 3;
var x3 = bind x2 on replace { foo() };

Both binds will be eager. When x1 changes, the on replace clause causes an implicit reference to x3, so its value is needed and its bind expression (x2) must be evaluated. To obtain the new value for x2, its bind expression (x1 * 3) must be evaluated.

Even though both binds in the example will be eager, side effects are still not allowed in their bind expressions. If a side effect of a bind expression is desired, it can sometimes be accomplished in an on replace clause, for example:

 var yy: Number;
 var xx = bind fred(zz) on replace {yy = zz};

New on invalidate clause and invalidate statement

The on invalidate clause and invalidate statement are new features in JavaFX 1.3. They can be used together with lazy binds to improve performance. An on invalidate clause is similar to an on replace clause in that it includes a block of code, and it can be added to a variable definition. However, an on invalidate clause does not force a bind to be eager as does an on replace clause. The semantics of this

 var y ... on invalidate {code block}

are that the code block is executed when y might have become invalid, (for example, when a new value has been designated for y), which means that the next reference to y must not get the old value of y. More specifically:

• If y is referenced two times and the second yields a different value than the first reference to y, then the on invalidate code block will have been executed at least once between the two references.
  
  
• If y is explicitly invalidated with the new invalidate statement. For example:
  
  invalidate y;

then the on invalidate code block will be executed at least once between the execution of the invalidate statement and the execution of the next reference to y.

New isReadOnly(xxx) synthetic method

isReadOnly is a synthetic method that takes a single argument, which must be a script or instance variable reference that is defined with a var (as opposed to an expression, or a variable defined with a def).

isReadOnly(xx) returns true if xx cannot be modified, otherwise it returns false. Currently, the only vars which are read-only are those defined with a bind without inverse.

For example:

var x;
var y = bind x;
var z = bind x with inverse;
println("is x bound ? {isReadOnly(x)}");
println("is y bound ? {isReadOnly(y)}");
println("is z bound ? {isReadOnly(z)}");

This code will print:

is x bound ? false
is y bound ? true
is z bound ? false

isReadOnly can be used in a member function to detect that a subclass has added a bind to an instance variable, which means that the variable must not be modified.

API Enhancements

A compatible API change is an addition to the API in the form of a new public or protected class, function, var, or def.

• New grow, shrink, and fill functions for Resizable
  
  

  The functions getHGrow, getHShrink, getVGrow, getVShrink, getHFill, and getVFill have been added to Resizable so that nodes can express their preferred resizing behaviors.

• New KeyCode variables to support TV remote controls
  
  

  The KeyCode class now contains the following additional codes to support TV remote controls:

  • VK_BACK
  • VK_CANCEL
  • VK_CHANNEL_DOWN
  • VK_CHANNEL_UP
  • VK_COLORED_KEY_0
  • VK_COLORED_KEY_1
  • VK_COLORED_KEY_2
  • VK_COLORED_KEY_3
  • VK_EJECT_TOGGLE
  • VK_FAST_FWD
  • VK_INFO
  • VK_MUTE
  • VK_PAUSE
  • VK_PLAY
  • VK_POWER
  • VK_RECORD
  • VK_REWIND
  • VK_STOP
  • VK_TRACK_NEXT
  • VK_TRACK_PREV
  • VK_VOLUME_DOWN
  • VK_VOLUME_UP
  
  
• Allow CustomNode to have multiple children to eliminate needing an extra Group.
  
  

  Previously, CustomNode returned a single node via its create() function. This meant that virtually every CustomNode object would create a Group to hold its content. For CustomNodes defined with a small number of shapes, the memory overhead of this Group was noticeable.

  This change addresses this issue as follows:

  • protected var children:Node[]; has been added to Parent.
    
    
  • The Group class now contains the following content implementation:
    
    

    public var content:Node[]; 
     override var children = bind content with inverse; 

  
  
  
  • CustomNode implementations can now either use the existing create() mechanism or add nodes directly to the children sequence.

• Multi line (single-style) support added to TextBox
  
  

  The TextBox class now supports multi line (single-style) text. For a tutorial about using this control, see Using JavaFX UI Controls.

• TextBox has been refactored
  
  

  TextBox has been refactored to support PasswordBox, SearchBox, and other text input controls. The purpose of this change is to reuse the common API/implementation between them.

• TextBox action() and commit() functions have been moved up to TextInputControl
  
  

  In this release, action and commit are defined in TextInputControl and then inherited into TextBox.

• New control key function support
  
  

  TextBox now supports the following control key functions:

  CTRL + HOME 
  CTRL + END 
  CTRL + RIGHT/LEFT ARROW 
  CTRL + SHIFT + RIGHT/LEFT ARROW 
  CTRL + SHIFT + HOME/END 
  

• New support for custom cursors
  
  

  The new javafx.scene.ImageCursor class provides a custom image representation of the mouse cursor. On platforms that don't support custom cursors, Cursor.DEFAULT will be used in place of the specified ImageCursor.

• New layout support for baseline alignment
  
  

  Vertical baseline alignment support has been integrated into all Containers and a subset of Controls: Label, CheckBox, Button, Hyperlink, RadioButton, ToggleButton, Slider, and TextBox. A new mixin class, TextOffsets, has been added that defines offsets needed to align nodes based on their text content. Controls can now be aligned in this manner by simply setting their nodeVPos to VPos.BASELINE. Since Container implements TextOffsets, all concrete Container classes have a baselineOffset variable which defaults to the baseline location of the first node in the Container object's managed content. To assist Container implementations in supporting baseline alignment for layout, various script-level utility functions have been added to Container:

  • public bound function getNodeBaselineOffset(node:Node):Number
  • public function getMaxBaselineOffset(content:Node[]):Number
  • public function positionNode(node:Node, areaX:Number, areaY:Number, areaWidth:Number, areaHeight:Number, areaBaselineOffset:Number, hpos:HPos, vpos:VPos, snapToPixel:Boolean):Void

• New layout support for snap-to-pixel
  
  

  In previous releases, the layout functions did not round to pixel boundaries, which could cause nodes to appear fuzzy. This change adds a snapToPixel variable to Container, plus versions of the layout utility functions that accept it as a parameter. This change also modifies all the concrete containers to properly call these functions.

• New PasswordBox control
  
  

  A new PasswordBox control has been added in this release. For a tutorial about this control, see Using JavaFX UI Controls.

• New margins and padding variables
  
  

  All containers now honor both node margins and container padding. public var margins:Insets has been added to LayoutInfo, and public var padding:Insets has been added to all other container classes.

• Layout Growing, Shrinking, & Filling
  
  

  In previous releases, the policy of how to resize a Resizable node within a given container's space was left solely up to the container. Additionally, when a container was resized larger (or smaller) than its preferred size, there was no way to specify how that increased (or decreased) space should be distributed across nodes. This change addresses the need to control more precisely how Resizables are resized given dynamically changing available space. This change enhances the LayoutInfo constraints to enable these details to be specified on a per-node basis within containers.

• New way to specify text bounds type
  
  

  This change adds a new boundsType variable to the Text node that affects whether the bounds are calculated as logical or visual bounds. (Logical bounds are better for component layout and performance. Visual bounds are better for precise positioning of specific text and will provide tighter bounds around that specific text.) TextBoundsType.LOGICAL is the default.

• Support for bounds-based picking of Text node
  
  

  The new Text.pickOnBounds variable defines how the picking computation is done for a node when triggered by a MouseEvent or a contains function call. If pickOnBounds is true, then picking is computed by intersecting with the bounds of the node, else picking is computed by intersecting with the geometric shape of the node. The default value for pickOnBounds for text nodes is true, meaning that you can pick anywhere in the string, including gaps between letters or holes within letters (for example, in the middle of an "O").

• Additional bitmap cache hinting to allow smoother animation
  
  

  A new Node.cacheHint variable was added to control caching, with values of: CacheHint.DEFAULT, CacheHint.SCALE, CacheHint.ROTATE, and CacheHint.SCALE_AND_ROTATE.

• DropShadow and InnerShadow now have input variable
  
  

  The DropShadow and InnerShadow classes now have public input variables.

• New API to Query "common conditional" features
  
  

  This change adds an API that allows developers to query which common conditional features are present in the system. Common conditional features may not be available on all platforms. An application that wants to know whether a particular feature is available may query this using the Platform.isSupported() function. Using a conditional feature on a platform that does not support it will not cause an exception. In general, the conditional feature will just be ignored.

• New Separator Control
  
  

  A new Separator control has been added in this release. For a tutorial on using this control, see Using JavaFX UI Controls.

• New API for disabling auto-sizing on Group objects
  
  

  A new Boolean variable autoSizeChildren has been added to Group. This variable makes it possible to disable any automatic autosizing behavior, eliminating the Group's active participation in layout. Doing so means that the application is taking responsibility to ensure that the children of that Group are being laid out another way, either by the Group's parent's doLayout() function or by explicit sizing and positioning.

• New ScrollView control
  
  

  A new ScrollView control has been added in this release. For a tutorial on using this control, see Using JavaFX UI Controls.

• New ChoiceBox Control
  
  

  A ChoiceBox control has been added in this release. For a tutorial on using this control, see Using JavaFX UI Controls.

• New Tooltip Control
  
  

  A Tooltip control has been added in this release. For a tutorial on using this control, see Using JavaFX UI Controls.

• Add asynchronous parse() to PullParser
  
  

  In this release, a new public class javafx.data.pull.ParserTask has been added.