JavaFX: Bringing Rich Experiences To All the Screens Of Your Life

Profile: desktop, common

JavaFX 1.0 API | Overview | Java FX

javafx.animation

Provides the set of classes for the time-based animation framework.

Provides the set of classes for the time-based animation framework.

This framework defines a mapping of time to values for the target variable. This variable transitions between the declared values at certain points in time, by using the declared interpolation function to calculate the in-between value.

 
javafx.lang

This package provides JavaFX Script Runtime APIs

This package provides JavaFX Script Runtime APIs

Builtins

This class is automatically imported to all JavaFX Scripts

FX

The FX class contains number of static entry points for a couple of different API sets provided by JavaFX Script.
  • Application Model

    JavaFX Script APIs are categorized into following profiles.

    • Common Profile

      This API is common across all platforms

    • Desktop Profile

      This API is available only in the desktop environment (browser & standalone)

    • Mobile Profile

      This API is available only in the mobile environment.

    If an application needs to be portable across all screens, it has to limit itself to common profile APIs. The JavaFX Script Runtime has the ability to run JavaFX Scripts that use the common or desktop API sets in any supported Browser.

  • Argument or Parameter Handling

    JavaFX Scripts can get Arguments or Parameters in 2 different forms

    • Named

      Named Parameters come in the form of a Name, Value pair typically from HTML, JAD or JNLP files. They can also be passed as a commandline argument in the form of "name=value".

      Use the getArgument() api for Named parameters

    • Unnamed

      Unnamed Arguments are always passed on the commandline.

      Use the FX.getArguments() api for Named parameters

    These cannot be combined, if they are it will behave as space seperated arguments.

  • SystemProperty information

 
javafx.reflect

Provides reflective access to JavaFX values and types.

Provides reflective access to JavaFX values and types. This packages defines a Java API (rather than a JavaFX API), so it can be used from both Java and JavaFX code. A future JavaFX API may be layered on top of this.

Context

The objects in this package are directly or indirectly created from a FXContext. In the default case there is a single FXContext instance that uses Java reflection. You get one of these by doing:
 FXLocal.Context ctx = FXLocal.getContext();
 
Alternatively, you can do:
 FXContext ctx = FXContext.getInstance();
 
The latter is more abstract (as it supports proxying for remote VMs) but the more specific FXLocal.Context supports some extra operations that only make sense for same-VM reflection.

Values

The various reflection operations do not directly use Java values. Instead, an javafx.reflect.FXObjectValue is a handle or proxy for an Object. This extra layer of indirection isn't needed in many cases, bur it is useful for remote invocation, remote control, or in general access to data in a different VM.

Object creation

To do the equivalent of the JavaFX code:
 var x = ...;
 var z = Foo { a: 10; b: bind x.y };
 
you can do:
 FXContext rcontext = ...;
 FXClassType cls = rcontext.findClass(...);
 FXObjectValue x = ...;
 FXObjectValue z = cls.allocation();
 z.initVar("a", ???);
 z.bindVar("b", ???);
 z = obj.initialize();
 

Sequence operations

Use javafx.reflect.FXSequenceBuilder to create a new sequence.

To get the number of items in a sequence, use ValueRef.getItemCount. To index into a sequence, use ValueRef.getItem.

Design notes and issues

Some design principles, influenced by the "Mirrored reflection" APIs (Bracha and Ungar: Mirrors: Design Principles for Meta-level Facilities of Object-Oritented Programming Languages, OOPSLA 2004), and JDI :
  • No explicit constructors in user code.
  • Keep everything abstract, and allow indirection. For example, we might be working on objects in the current VM, or a remote VM. We might not have objects at all - a subset of the same API might be used for (say) reading from .class files.
  • Hence the core classes are interfaces or abstract.
  • On the other hand, we should avoid useless levels of indirection or "service lookup".

Limitations

  • Error handling isn't very consistent - sometimes we return null, and sometimes we throw an exception.
  • We don't support bound functions properly.

 
javafx.util