Monday, February 8, 2010

Getting Started with JavaFx

As my last posting noted, I'm intrigued by the JavaFx language. It's being marketed as a platform for Rich Internet Applications (RIAs), in competition with Flash (Flex) and Silverlight. I don't think it's going to be successful in that space, for reasons that I'll detail in a future post. However, it might just be the next big language for the JVM platform, a functional-object language with the marketing muscle of Oracle behind it.

With that in mind, I'm taking some time to investigate the language, and will be writing a series of posts about it. I won't spend a lot of time on the GUI aspects; there are already blogs that do that, and a whole page of examples with source code. Instead, I want to point out some of the things that I think are neat about the language, and some of the roadblocks that might be in its way as a general-purpose environment.

There will be a few code snippets along the way. You can compile and run them from the command line, using the javafxc and javafx tools from the SDK. There's also IDE support for NetBeans 6.x and Eclipse. I use the NetBeans plugin, and it seems fairly solid (although there seem to be some issues with NetBeans on Ubuntu 9.04 — sometimes it stops accepting keystrokes until I switch windows). If you don't already have NetBeans, you can download it pre-configured with JavaFx, from the JavaFx downloads page (and you'll find the SDK there too).

Before diving into code, there are a couple of terms that have special meaning with JavaFx:

A JavaFx source file. Although called a “script,” these files must be compiled into Java bytecode, and run from within the JavaFx environment. Scripts are translated into top-level Java classes with predefined methods used to invoke the script (think of main()), along with the various methods, variables, and code defined by the script.
Much like a class in any other language: a definition that combines data and methods, and must be instantiated for use. JavaFx classes are defined within a script, and the compiler creates nested Java classes to represent them.

Now it's time for “Hello, World”:

package experiments.language;

println("Hello, World");

That's it. It really does look like a script: there's no boilerplate class definition, no public static void main definition. Even the println() statement gives no hint that it's actually implemented by the class javafx.lang.Builtins.

All of this, however, is simply syntactic sugar: you could easily write a precompiler that takes a similar script and adds the boilerplate Java code. I'll leave you with something new, however: inline variable substitution, a la PHP:

package experiments.language;

def addressee = "World";
println("Hello, {addressee}");

No comments: