Tuesday Feb 28, 2012

JavaFX 1.2 and JavaFX 1.3 EOL Announcement

December 21, 2012

Update: JavaFX 1.2 and JavaFX 1.3 Runtime Downloads to Remain Available Until End of March 2013

In order to allow specific companies to finalize the migration of their JavaFX Script-based applications to JavaFX 2, the JavaFX 1.2 and 1.3 Runtime products will remain available until the end of March, 2013, unless the server hosting these downloads is affected by a technical issue.

February 28, 2012

Original  JavaFX 1.2 and JavaFX 1.3 EOL Announcement

Back in September 2010, during the JavaOne conference in San Francisco, Oracle announced they were discontinuing the JavaFX Script language. Oracle also committed to expose all the JavaFX functionality through a Java API, starting with the upcoming JavaFX 2.0 release. As promised, the Windows version of JavaFX 2.0 and the Developer Preview for Mac OS X were released in October 2011; a Developer Preview for Linux was added in January 2012.

Today, we are announcing that JavaFX 1.2 and JavaFX 1.3 will reach end of life (EOL) on December 20, 2012. More specifically, the Oracle server providing access to the JavaFX Runtime for these versions will no longer be available after that date.

Because of the specific deployment architecture used for the JavaFX 1.x product line, this means that users of JavaFX 1.2 or 1.3 applications will no longer be able to download the JavaFX Runtime. Therefore, companies and developers who have JavaFX 1.x applications in use today are strongly encouraged to migrate their applications to the JavaFX 2, which is currently available on Windows, Mac OS X and Linux. Extensive documentation, tutorials, and samples are available on the JavaFX Website, and a growing developer community has started sharing its experience and providing advise on forums, blogs, or social media.

Please refer to the JavaFX website for more information about the current version of JavaFX. You may also discuss specific issues related to this announcement on the JavaFX OTN forum, which we monitor on a regular basis.

Friday Feb 24, 2012

Communicating between JavaScript and JavaFX with WebEngine

Content by Peter Zhelezniakov

JavaFX 2 has introduced the WebEngine and WebView classes to support modern Web standards such as JavaScript, CSS, SVG, and a subset of HTML5.

Besides browsing Web pages, WebEngine can also serve as a container to host Web applications. Running standalone Web applications inside JavaFX is not very exciting though. You can do the same with any browser. What makes it interesting is the fact that the a Web application can communicate with its hosting JavaFX application, enabling a two-way communication channel. This article describes how this channel works in the JavaFX 2.1 Developer Preview.

Invoking JavaScript from JavaFX

The Java application can pass arbitrary scripts to the JavaScript engine of a WebEngine object by calling the WebEngine.executeScript() method:


The script is executed within the context of the current page. The result of the script invocation is converted to a Java type and returned. For the primitive types, the conversion is straightforward: integer values are converted to Integer, strings to String, etc. Most JavaScript objects are wrapped as instances of the netscape.javascript.JSObject class well-known to LiveConnect developers. Its methods are shown below:

public Object call(String methodName, Object... args);
public Object eval(String s);
public Object getMember(String name);
public void setMember(String name, Object value);
public void removeMember(String name);
public Object getSlot(int index);
public void setSlot(int index, Object value);

So, here is another way to go back one history item in a browser:

JSObject history = (JSObject) webEngine.executeScript("history");

This example shows an interesting aspect of extending the WebEngine functionality. The WebEngine API, as of writing this, is deliberately limited to just a few methods that are considered critically important. However, the WebEngine class supports the much broader JavaScript API. You can use the executeScript() and JSObject methods to enable this second layer of API and get access to the functionality you miss. So, while there's no a Java method like goBack(), a similar JavaScript method exists and can be invoked as in the above example.

The JSObject methods apply the same conversion rules to the values they return as executeScript(). For example, the following method returns an instance of java.lang.Integer:


A special case is when a JavaScript call returns a DOM Node. In this case, the result is wrapped in an instance of JSObject that also implements org.w3c.dom.Node.

Element p = (Element) webEngine.executeScript("document.getElementById('para')");
p.setAttribute("style", "font-weight: bold");

In this example, the script result is an Element object, and it is wrapped as org.w3c.dom.Element instance.

Making Upcalls from JavaScript to JavaFX

Since we are talking about a two-way communication channel, what about making calls in the opposite direction: from a Web application into JavaFX? On the JavaFX side, you need to create an interface object (of any class) and make it known to JavaScript by calling JSObject.setMember(). Having performed this, you can call public methods from JavaScript and access public fields of that object.

The code below shows how to set up an interface object:

class Bridge {
    public void exit() {
JSObject jsobj = (JSObject) webEngine.executeScript("window");
jsobj.setMember("java", new Bridge());

First we need a JSObject to attach our interface object to. The above code uses the JavaScript window object but any other object would work as well. Note that a cast is necessary. Then we create an interface object and add it as a new member of that JSObject. It becomes known to JavaScript under the name window.java, or just java, and its only method can be called from JavaScript as java.exit(). The upcall into Java is synchronous and occurs on the JavaFX Application thread. The following HTML code enables exiting the JavaFX application by clicking on a link:

<a href="" onclick="java.exit();">here</a>
to exit the application

Once you no longer need an interface object, you may want to call the JSObject.removeMember() method to make JavaScript "forget" it.

A Note about Security

Please be careful about functionality you open to JavaScript. Remember, there is no sandbox for standalone applications. Methods called by JavaScript on the interface object are invoked directly, as if they were called from your JavaFX code. If your application enables browsing arbitrary Web pages, a malicious script may take advantage of the ability to run Java methods with the user's permissions. So you probably do not want to write

jsobj.setMember("filesys", new File("/"));

as this would let scripts browse about the whole filesystem. By carefully designing the interface object, you can always make sure that only safe functionality is exposed. Another idea is to install and configure a security manager in your application.

Tuesday Feb 21, 2012

JavaFX 2 and the developer community

JavaFX 2 was only released in October 2011, but there's already a thriving developer community kicking the tires of the new kid on the block, or busy developing new applications. There's no denying that we've pretty much started from scratch with JavaFX 2, and that we still have a lot of work ahead of us before we can claim victory.

But based on a number of indicators, JavaFX 2 benefits from the support of a growing number of developers. Let's have a look at some of these metrics.

JavaFX OTN Forum

There are currently two forums covering JavaFX. The first one covers JavaFX 1.x, and the activity on that forum has pretty much stopped several months ago, which was to be expected since JavaFX 1.3.1 is the last release supporting JavaFX Script.

On the other hand, the number of discussion threads on the "JavaFX 2.0 and later" forum has been growing steadily since the initial JavaFX 2 Beta for Windows was made available for download last May. A large number of the questions asked on the forum are answered by members of the JavaFX product team at Oracle, but an even higher number of threads involve non-Oracle employees. All in all, this is a sign of an healthy developer ecosystem: more and more developers start experimenting with JavaFX 2, ask questions on the forum, which should ultimately translate into more knowledgeable developers capable of building functional JavaFX applications.

Filing Bugs and Feature Requests

Another sign of a healthy developer ecosystem is the willingness of developers to report issues or submit a request for a new feature, rather than hoping someone else will do it, or moving away from JavaFX. For JavaFX 2, the developer community has contributed to an average of 20% of the activity in Jira since July, which is helping us produce better quality releases, since we can't possibly replicate all the software combinations in our QA lab.


As many of you know, my Tweeter id is @javafx4you, and I try to do my best identifying the most interesting JavaFX-related announcements and blog posts to provide a stream of relevant information on Tweeter. Over time, a growing number of people interested in JavaFX are following me, and this number keeps growing. Of course this number is small compared to the number of followers for  @java or @openjdk, but again JavaFX 2 is pretty new, and it's the trend that is interesting.


I enjoy reading blog entries focusing on JavaFX, because it gives me an opportunity to see what other developers think of JavaFX, or discover new uses that we didn't originally envision. My biggest frustration is actually not being able to find out the real name and contact information for the person who has written a terrific blog entry about JavaFX, because I'd like to help put them in touch with our Java Magazine and OTN editor-in-chief, or simply set up a discussion with folks in our development team.

It's of course impossible to track all blogs that mention JavaFX, so I've decided to rely on the excellent summary "JavaFX links of the week" posted on a regular basis by Jonathan Giles. Not scientific, but good enough to se the trend in number of blog entries.


There are many other metrics one can consider, such as the number of JavaFX SDK downloads, the number of JavaFX session attendees at JavaOne, or even the results of informal polls, such as the one posted by Kevin Farrell on java.net (Will you use JavaFX for development once it's fully ported to Mac and Linux platforms?), but pretty much all the ones I've seen show that JavaFX is growing in terms of popularity.

The challenge is of course to keep the trend going, and you can certainly play an important role. Remember: download, kick the tires, file issues, ask or answer questions in the forum, post your thoughts in blog entries, and release new apps!

Tuesday Feb 14, 2012

New JavaFX documentation: Concurrency, SWT

The JavaFX documentation team has taken advantage of the JavaFX 2.0.3 update release to publish two new documents:

  • Concurrency in JavaFX
    This article describes the capabilities provided by the javafx.concurrent package to create multithreaded applications. You learn how to keep your JavaFX application user interface (UI) responsive by delegating time-consuming task execution to background threads.

  • JavaFX Interoperability with SWT
    This article shows how to add a JavaFX scene graph to a Standard Widget Toolkit (SWT) application, and how to make SWT and JavaFX controls interoperate.

  • A few other documents have been updated as follows:

And if you are new to JavaFX 2, you should definitely have a look at the full JavaFX documentation.



This blog is maintained by Nicolas Lorain, Java Client Product Manager. The views expressed on this blog are my own & do not necessarily reflect the views of Oracle.


« February 2012 »