JavaFX: Current Status and What’s Upcoming
Haase provided InfoQ.com readers a brief overview of JavaFX, along with a few examples of where it might be useful in the future for building Rich Internet Applications:
JavaFX Script is a new language that builds upon the capabilities of the existing Java platform. It offers new capabilities and new syntax that can make it easier to, for example, build graphical and Graphical User Interface (GUI) applications.On the current status of the OpenJFX project:
It is obviously possible to write rich, dynamic GUI applications now using the Swing and Java 2D libraries of Java, but it is not necessarily easy to do so. JavaFX Script makes these kinds of applications easier. For the Java developer, this means it makes their job easier, while building upon knowledge and skills that they have developed already with the platform. For other developers that do not use the Java platform, it means that they can now take advantage of the richness and power of the platform, while doing so with a language that is potentially easier for them to learn and to use.
OpenJFX is the site where development of various parts of JavaFX is happening in the open. For example, the compiler that is being written for JavaFX Script is being developed at the OpenJFX site, so that developers interested in trying out the early versions can grab the latest copy for themselves and even pitch in with suggestions and feedback for the development group.Haase described the JavaFX component model:
OpenJFX is also where various other projects are, or will be, hosted or linked to. For example, the Scene Graph project, a runtime library that enables some of the graphical, GUI, and animation capabilities of JavaFX Script, is linked from OpenJFX.
Finally, OpenJFX is the source for the current documentation of the project; tutorials, reference materials, and links to blogs and other resources are all hosted on the OpenJFX site.
I think of JavaFX Script's component model as Swing++--, if that statement compiles. That is, many of the components in JavaFX Script, such as a button, rely on the capabilities in the underlying Swing platform directly. So, a JavaFX Script button really is a Swing JButton.Haase was asked about one of the common criticisms of JSF (fair or unfair) - that it provides a framework for building UI components, but does not directly provide all the components needed for easily building a quality UI. He was asked how JavaFX approaches components differently:
But there are some important differences. For example:
- Where it doesn't make sense to propagate methods and fields that happen to be public in some Swing component, JavaFX Script's version of that object may choose to not have those fields and will thus be simpler to understand and program.
- JavaFX Script components layer functionality on top of underlying components by adding capabilities that the FX runtime can take advantage of. For example, one of the cool, new capabilities of the JavaFX Script language is the ability to trigger off of changes in field values in arbitrary objects. This happens for components by making sure that the FX wrapper class for any underlying component, such as a button, propagates changes appropriately to the JavaFX Script layer.
- JavaFX Script may also offer some components and other GUI objects that simply aren't available in Swing itself. For example, the current JavaFX Script version offers the VBox and HBox container objects that impose a simple vertical (VBox) or horizontal (HBox) layout constraint on their children.
I can't address the concern about JSF (not knowing enough about JSF, myself), but JavaFX Script will happily be able to take advantage of the full power of the Java platform for its component model. One of the strengths of Swing has always been its breadth of GUI components, as well as its flexibility in being able to add, more or, custom components to the mix. Since JavaFX Script layers on top of Swing, this strength carries right on through this new language.Haase on deploying JavaFX applications:
JavaFX Script applications will be deployable in the same way that Java applications are deployed: as standalone applications, as applets running in a browser, and as Java Web Start applications (which can be deployed over the web, but essentially run standalone on the desktop, within a secure sandbox environment).Haase was asked about plans for a browser plug-in similar to Silverlight or the Flash Player:
We already have a browser plug-in for Java, which we cleverly refer to as "Java Plug-In." JavaFX Script applications will be able to use this plug-in just like Java applications do. However, we are in the midst of revamping support for this plug-in in some critically important ways, especially as we move toward supporting more consumer-oriented JavaFX applications. For example, the improvements in startup time should make plug-in startup time, for both Java and JavaFX applications, markedly better than it is today. Also, we are rewriting the plug-in code virtually from scratch to be more robust and flexible. These two improvements are scheduled to be released in the "Java SE 6, Update 10" release, which you can get in early access form at the following site: https://jdk6.dev.java.net/6uNea.htmlOn comparing JavaFX with Adobe Flex/AIR, Silverlight, and other Rich Internet platforms in: features, deployment, and maturity:
I think I'd rather steer clear of direct comparisons at this time because, for one thing, we are clearly mid-development with Java FX, so any comparisons to released products would be premature. I will say that one of the true strengths of JavaFX in the RIA space is the power, functionality, and maturity of the underlying Java platform upon which it is based.In closing:
We're interested in the community's help. Come to the OpenJFX site, check out the latest releases, stay tuned with what's going on, write some JavaFX Script applications, and send us feedback on what you find out!Hopefully the OpenJFX project achieves all of its goals and gives Java developers a strong choice for building RIAs.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015