Syntax Matters: JavaFX Script

Last night I finished writing an article on JavaFX. It was a lot of fun, and it has convinced me that JavaFX has a strong future. A lot of its promise comes from its syntax. It is easy to get carried away with Rich Media! and Animation! and FPS! but then you forget that JavaFX is a new programming language on the JVM. Here are the highlights of its syntax.

The declarative constructors: When I first started looking at JavaFX, it looked like MXML but in a JSON format. Looks are deceiving. Essentially JavaFX supports name parameters in its constructors. The naming convention is foo : bar, where foo is the name of the parameter and bar is the value. You can put multiple parameters on one line by using a comma to separate, like in most other languages, or you can put each on its own line and eschew the commas. This leads to the JSON-ish syntax. It is probably more accurate to describe it as JavaScript-ish. This becomes even more apparent when you start nesting constructed objects. It really looks a lot like object literals in JavaScript. What is great is that this is not just something you only use for UI elements, like MXML. It is part of the language syntax, so you can use this syntax anywhere you want. Imagine being able to write an MXML expression directly inside a block of ActionScript code...

Speaking of JavaScript: A lot of the syntax of JavaFX looks like JavaScript's more sophisticated cousin, ActionScript 3.0. You use var to declare local variables. You put the type after the variable name, separated with a colon. You use function to define methods. The major difference is using def to denote a constant. In ActionScript, you use const, like you would in C. This is actually kind of bad in my opinion. The def keyword is used in many other languages, like Ruby and Scala, to denote a function. There is no obvious connection between def and a constant. I think they should have used const instead of def. It would have made more sense to do that and maybe use def instead of function.

Functional Programming: A lot of folks are disappointed that closures are not being added to Java, at least not in Java 7. JavaFX does have closures. You can define a var to have a function type and can specify the signature of that function. The syntax is pretty nice. For example, you could do var join:function(String[], String):String to define a variable called join that is a function that takes in an array of strings and a string as input parameters and returns a string. I would like to see this is in ActionScript. JavaFX also has support for list comprehensions. You could do var squares = for (i in [1..100]) { i*i} to get an array of the perfect sqaures up to 10,000. However, JavaFX does not make as much use of closures. You would think that its sequences would have common functional mehtods like filter, map, fold, etc. For filter and map, there are alternatives. For example, let's say you wanted the square of all of the odd integers less than 100. In Scala you would do something like val os = (1 until 100).filter(_ % 2 == 1).map(_^2) . In JavaFX it would be val os = for (x in [1..10][i | i % 2 == 1]){ x*x }. It's a case of syntax over API. The second set of curly braces is like a select clause. I want to like it because it uses mathematics insired symbols.

Other: There are a few other JavaFX syntax bits worth mentioning. First is bind and bound. These are for data binding expressions. These can be very powerful. You can bind variables together, so that the one changes when the other changes. Better is that you can bind to functions and list comprehensions. The other interesting syntax in JavaFX involve the keywords delete and insert. These give LINQ-ish syntax for sequences. In fact if you combine the mathematical style select syntax with insert/delete and with the declarative constructors, you get expressiveness that is pretty on-par with LINQ in my opinion. When you see everything working together, it kind of makes sense but it does seem kind of random at first.

JavaFX Performance

Recently I did a comparison of JavaFX performance vs. Scala. I did this mostly for kicks, and because some people thought that Mr. JavaFX was picking on other, non-Java languages that run on the VM. James Iry duly pointed out that JavaFX should be benchmarked against the likes of Ruby, Groovy, or Scala. It is meant to be a client-side technology, so it should go up against client-side technologies. So I re-did the little performance comparison to match JavaFX against JavaScript, ActionScript (Flash), and C# (Silverlight).

A comparison like this really becomes a comparison of Virtual Machines. For JavaScript there are a lot of choices. I decided to go with some that are supposed to be fast: Google Chrome, Firefox 3.1 (beta 2), and Safari 4 (developer preview.) Because I wanted Chrome involved, I had to go Windows. So I ran everything under Windows XP, running under Parallels on my MacBook. Here is the pretty graph:

I was just a little surprised by these results. JavaFX is indeed the fastest, but just barely. I was somewhat shocked to see Chrome's V8 JS engine right behind. In fact the difference is negligible for small iterations (shown above.) At larger iterations, JavaFX maintained 20-40% margin. As you can see from the graph, Flash and Silverlight were kneck-and-kneck as well, but was always about 7-10x slower than Chrome/JavaFX. Safari and Firefox were very underwhelming.

Of course this was just a micro-benchmark. The code just does a series of recursive calls. So what were are really measuring is the ability of the VMs to unwind these recursive calls. It is not suprising that HotSpot handles this easily. Actually, the same code in straight Java is much faster than the JavaFX version. It is surprising to see how well V8 handles this.

Now does the ability to unwind recursion translate into performance that a web application user would notice? Maybe. It certainly points to JavaFX's or V8's ability to make optimizations to application code. It is probably a more meaningful test than some raw number crunching.

JavaFX vs. Scala

Chris Oliver post a nice little performance comparison of JavaFX vs. Groovy and JRuby. He concluded that JavaFX was 25x faster than these other two languages running on the JVM. Of course I had to see how this compared to Scala. First here's the direct translation to Scala I did of the code:

object Tak{
 def tak(x:Int, y:Int,z:Int):Int = if (y >= x) z else tak(tak(x-1, y, z),tak(y-1, z, x),tak(z-1, x, y))
 def main(args:Array[String]) = {
  0 until 1000 foreach ((i) => tak(24,16,8)) 
 }
}

Here are the results for JavaFX on my MacBook:

$ time javafx -server -cp . tak

real 0m12.847s
user 0m11.926s
sys 0m0.338s

So my system is a little slower than Chris Oliver's. That's why I had to run his bench on my MacBook first, to make a fair comparison to the Scala version. Here are those results.

$ time scala Tak

real 0m9.690s
user 0m9.122s
sys 0m0.261s

Scala not only beat out JavaFX on my system, but was also faster than JavaFX running on Chris Oliver's faster system. The guys at Sun should have never let Odersky go!

JavaFX: Some Frustrations...

Yesterday was the much ballyhooed release of JavaFX. I was excited about this for a few reasons. First, I started following JavaFX back when it was called F3. I remember last year planning on attending Chris Oliver's session at JavaOne on F3, when I read on his blog that F3 was now being called JavaFX. Second, a big part of my job is staying on top of RIA technologies and JavaFX certainly falls in that category. Lastly, it's a new programing language that runs on the JVM! How could I not want to learn it.

So I started playing around with JavaFX. Instead of going after lots of graphical goodness, I went for more mathematical stuff. I did a few problems with JavaFX, and then came across a problem that required finding the prime factors of a large integer. JavaFX has an Integer type that maps to java.lang.Integer. There is nothing in JavaFX specifically for large integers, but part of the beauty of JavaFX is that you can use classes from Java in it. In particular you can use java.math.BigInteger. So far so good.

In my solution, I wrote a prime sieve and then checked the modulus of the primes against the large integer. Now for normal 32-bit Integers, JavaFX has some nice syntax:

var remainder = n mod p;

It looks like math! Of course I love this. However, this does not work for BigIntegers. No problem, BigInteger has its own method for this:

var remainder = n.mod(p);

But this does not compile! Why? As you can infer from the first example, mod is a reserved word in JavaFX, so you can't use it as an identifier. Thus you can't use it as a method name. Of course you could surely use reflection to get around this, but who wants to do that?

JavaOne 2008

I've been at JavaOne all week, but not blogging. That is partially because of the horrible Wi-Fi at JavaOne this year. Luckily it is good today, so I am blogging before Josh Bloch's Effective Java talk. I also just picked up the new edition of Effective Java, as if I could somehow read the whole thing before the talk ... Probably should have waited to buy it at the end of the day since I won't be reading it until the train ride home. Anyways...

So what's been good at JavaOne this year? Well ... no big news, really. We see more meat on JavaFX and I guess that was the lead story at the opening keynote. It seems like JFX is about where Silverlight was a year ago. The JVM 6, update 10 does rock. You can do so much more with Java than with Flash or Silverlight, regardless of JFX, so it will be interesting to see if people leverage that.

Along those lines, the most interesting session I saw this week was by the guys from Ajaxian, Dion Almaer and Ben Galbraith. Their talk was titled "What's new in Ajax." The subject matter was interesting, but that's not what made their talk so awesome. They are outstanding speakers, and they seem to have a great rapport between them. Their talk seemed very conversational. It also definitely stood out for NOT having to follow the Sun presentation template. It was a Keynote presentation full of cool graphics, animations, and even some short video interviews with some of the top dogs in the world of Ajax frameworks. 

They also did two cool demos, one with Fluid. I fee like such a nov for not having seen this before. It is awesome. They also did an awesome demo where they "threw" a dart at a dart board. The dart board was an Ajax app running the in the browser. The dart was a Wiimote! They used the Bluetooth connection of the Wiimote to send to the PC, and then bridged the Bluetooth stack on the PC to the browser using (drum roll please) a Java applet. The applet was just for communicating with the OS, all of the graphics were in HTML and the interactivity was JavaScript. Very freakin' cool. 

The other good session I went to was Alex Miller's talk on design patterns. Most of this was stuff I was familiar with, like problems with the Singleton and Visitor patterns. What was interesting to me was that Alex showed how closures could dramatically change the implementation of some of these patterns. He showed this for a template pattern. Both template and strategy patterns are kind of obvious targets for refactoring with closures. What surprised me was how a visitor pattern could be refactored using closures. I was inspired to start playing with design patterns in Scala, since that is the future of Java (in my opinion.) I tweeted this to Alex, and he pointed me to some writings on that exact topic. I still plan on doing my own exposition, as I think it will be fun.

Silverlight and Flex in the Browser

The web browser is one of the great equalizers of the world. It's why Microsoft feared Netscape. If something runs in the browser, it doesn't matter where it came from. HTML, JavaScript, CSS are agnostic of the technology used to generate them. Don't get me wrong, browsers have their "quirks" and certain technologies make use of these quirks more readily than others, but these things aren't coupled. I can create an XHTML compliant application using ASP.NET and C# just as easily as I can create an app that uses lots of IE-only HTML and JavaScript using PHP.

There is an exception to this uniformity and that comes from browser extensions/plug-ins. These are capable of doing more proprietary communication with back-end servers. In a world where a new rich internet application framework is being introduced by some multi-billion dollar software company each month, one could easily imagine a tight coupling between such frameworks and the server technologies that feed them.

Of course the mother of these new frameworks is Flex, Adobe's application platform built on top of Flash. One of the common companions to Flex is Flex Data Services. This is actually an Enterprise Java application for accessing enterprise resources (like databases) and serving up data to Flex clients. One would guess that you could do the same thing on your own, and not just in Java. Your Flex client makes gets/posts to a URL and parses the response for a data model. You could even use SOAP for all this, if you were a masochist.

The design behind Silverlight seems very similar. The quick start tutorials from Microsoft show a Silverlight client connecting to a web service. Thus it should not be too hard to build a Silverlight application that talks to a Java or PHP server. On a side note, I had one interesting realization from reading through some of the Silverlight tutorials. They make a big deal distinguishing between client-side Silverlight code written in managed CLR (i.e. C# or VB.NET) as opposed to code written in a scripting language such as JavaScript or Iron Python. My understanding of the CLR was that everything was compiled into Intermediate Language (IL.) It sounds like if you use C# for your Silverlight project, then this is the case, but not if you use Python. This seems ... odd. One approach I thought they might try was to compile everything into JavaScript and let IE's runtime handle it ... but then I remembered that they are providing Silverlight for Firefox and Safari.

So my plan now is to take the Stocks application I wrote for the GWT tutorial (part is out next week, by the way) and create a Flex and Silverlight version of the same thing. I might cheat and re-use the servlet that GWT creates, or I might create a REST servlet. Too bad there are JSR 311 implementations yet.

Oh yeah, and then there's JavaFX. There is a fair amount of JavaFX documentation and examples. However, I'm not really sure if JFX will use a similar mechanism as Flex and Silverlight. It seems like it has to. The example I've seen usually create all the JFX on the server and then ship it to the client for rendering. That approach seems kind of primitive and something that would be difficult for an interactive application (like the the stock application.) Maybe by the time I'm done with the Flex and Silverlight versions of things, it will be more obvious how to do the same thing with JFX.

JavaFX Tools

As I mentioned earlier, I gave the JavaFX plugin for Eclipse a try. I was not too impressed. So I went through the monstorous download of NetBeans 6.0 and installed the JFX plugin for it. I'm still not too impressed!


Again this was basically just a text editor with the JFX runtime automatically launched. No palette or even much code completion. There was a little syntax highlighting, but that was about it.
Ok, so I know this stuff is really new, and I shouldn't be too critical of it. However, I read this exerpt from an interview with Sun CEO Jonathan Schwarts from OnJava:

In response to a question about JavaFX and JavaFX Tools. Whether Sun was planning on charging for FX tools.

Schwartz: “The world is divided into two camps, those who can and will pay for technology because its expense is less than the inconvenience of not having a support contract and those who cannot and will not pay for software for whatever reason, economically, culturally or the business just doesn’t need it. Our economic motives are to go after the former camp, our technology objectives are to go after the latter camp. Because almost by definition given what Dr. Diallo(sp?) just said, they out number the former camp 50,000 to 1. So volume defines market opportunities for everybody, you need only look at the internet to have that proven to you. It’s up to us to figure out how to monetize those volume opportunities in and among the communities that are capable and interested in doing so.”

Hmm. So now I'm thinking that designer like tools for JFX will be coming, but they won't be plugins to Eclipse and NetBeans. The big advantage I thought JFX might have over Flex and Silverlight was its free-ness and open source-ness. Not only would that make it attractive to adopt but would also open up third party enhancements. What's a Java technology without at least a dozen different frameworks built for it?

Now I'm thinking that this won't be the case. Sun will try to monetize JFX in the exact same way that Adobe and Microsoft monetize Flex and Silverlight. There's nothing wrong with this, it just means that JFX won't have one potential advantage over those technologies. That doesn't mean it won't have other advantages, as mentioned in previous posts. Its architecture may make it much more suitable for designer-developer workflows and rapid development.

I still think Sun is missing a huge opportunity. They could be the disruptive technology in all this, but it sounds like they won't go that route. So much for "Open Possibilities."

JavaFX Presentation at JavaOne

The transformation of F3 into JavaFX continues. I had signed up for the Form Follows Function (F3) session, but F3 was renamed JavaFX yesterday and now even the session title has been renamed: JavaFX Script. Chris Oliver is getting ready to make his presentation. The program on the projector says "JavaFX PDF Reader." So maybe he is going to use a JavaFX app to show the slides for the presentation. One can imagine a PowerPoint -> PDF -> JavaFX workflow here. If this is the case, it's a nice touch since it's a classic "eating your own dog food" tactic. Let's see…

The JFX (as Chris Oliver started calling it) presentation was very cool. Chris talked about his motivation for JFX. The first was that developers tended to be the limiting reagent in UI development, i.e. they took much more time than designers did. Web UIs were often used for prototyping for this very reason. Java/Swing UIs are often stereotyped as being very ugly, quite unlike Flash based apps. The last (and maybe most important) factor was that event listeners became a huge mess in UI code.

To tackle the first set of problems, JFX leverages Java 2D instead of Swing. The constructs used by designers have analogies in Java 2D, not in Swing. JFX brings a lot of the techniques of Swing to Java 2D. It uses a declarative syntax for this and allows for composition a la Swing, but Java 2D powers the building block components of JFX. This is very cool. The idea here is that anything you can do with Flash (and Silverlight!) can be done with Java 2D, and now can be easily done with JFX.

The next, and maybe more crucial aspect, was the elimination of event listeners in JFX. JFX uses a bidirectional update system that makes everything seamless to the developer. If the server updates a component it is re-rendered automagically. If a user invokes an action, the server side state is synchronized effortlessly. This was pretty impressive. As somebody who has designed a UI language (at Ludi Labs) I was especially impressed. We tackled the same problem there by auto-generating the event listeners essentially. I'm curious if this is what JFX is doing. Chris mentioned his inspiration came from functional programming, so maybe he came up with a more elegant approach.

Finally, among the demos was indeed the PDF reader I mentioned at the beginning of the post. Indeed all the slides were being displayed using the JFX PDF viewer. It was a very slick PDF viewer, with nice animations, zoom, page previews, etc. Chris got a great reaction when "revealed" that his PDF reader was a JFX application.

So what do I conclude from all this? Glad you asked. JFX has a design that really sets it apart from anything out there. There's a lot more going on here than just a Flex clone. That definitely is part of it, as Chris was quick to admit. Flex looks nice. Nice looking apps is only part of the equation. Improving UI development is a bigger puzzle to solve. JFX looks like it can deliver. It just needs the tooling for the designers to go along with it. More on that later.

One final observation. It really seemed like Chris Oliver was as surprised as anyone that F3 became JavaFX and thus the "big announcement" of JavaOne. Sun seems to be pushing JFX using the mobility angle (including all this nonsense about Blue-Ray devices.) There was no mention of that by Chris.

JavaFX

I guess the big news out of JavaOne today is JavaFX. The more I heard about it, the more it sounded familiar. Sure there's the obvious comparisons to Flex and SilverLight (more on that soon) but there was something even more familiar about it. Then I realized it: F3! I had read about F3 just last week (you can see it on my del.icio.us links) and had given it a try. So it turns I've already been running JavaFX.. Here's a picture of the F3 Calculator running on my laptop:

One of the most interesting things is the white space on my desktop. The F3 Calculator is part of it actually (or vice versa really.) There's probably some bugs to be worked on here! Also notice the little F3 icon in my system tray. You have to use that to close the calculator. The whole thing launches using Java Web Start, which is a good thing.

So yeah, JavaFX has a lot in common with Flex and SilverLight. Even in name. Microsoft had WinFX which became Windows Presentation Foundation which became Windows Presentation Foundation / Everywhere which became SilverLight. I'll say some of the same things about JavaFX as I said about SilverLight. If they could actually achieve "my dream" of writing a UI once and having it render nicely as a web app, a desktop app, and (most importantly) a mobile app, then it will be a huge success. I don't think anyone is close to that, yet.

JavaFX could actually have a lot more legs to it than SilverLight. It will be completely open, unlike either of its competitors. That should give it a huge advantage. That open nature should also mean a lot of creative integrations with the huge open source Java ecosystem. That's how JavaFX could win over developers. The key will be for Sun et. al. to deliver adequate tooling for it, as it is a UI language. Adobe already provides good tooling and Microsoft is sure to do the same. Sun's doesn't have to be as good as the Flex/SilverLight tooling, but it needs to be close. If it's not as good, you can expect to see other folks in the Java community step in.

Speaking of tooling, Cedric has a good rant against JavaFX. He smelled Sun trying to get people to use NetBeans, but as you'll see in the comments, there is an Eclipse plugin. Maybe the Jigloo guys can work with it, too. The better point that he makes is that Groovy SwingBuilder does a lot of the things that JavaFX promises to do. Maybe Sun should have leveraged that. I haven't tried JavaFX out yet, so I can't say if it has any syntactical advantages over Groovy. I must agree with another commenter that Sun doesn't seem too fond of Groovy. They seem much more interested in embracing Ruby via JRuby.

Update: I tried out the JavaFX plugin for Eclipse last night. It is quite bare-bones. It basically just lets you run a .fx file from Eclipse. No visual editing. It didn't even seem like there was any extra syntax help. I will try out the NetBeans one, but it sure looks like Cedric was right on about Sun once again trying to push NetBeans on people.