Thursday, February 4, 2010

Book Review: Essential JavaFx

I recently received a copy of Essential JavaFx as book give-away at my local Java Users Group meeting. The JUG receives such books directly from publishers, with the expectation that JUG members will write reviews. My review of this book follows; I suspect that Dave won't be sending it back to the publisher.


My bookshelf holds a dog-eared copy of The UNIX C Shell Field Guide, written by Gail and Paul Anderson in 1986. To me, it represents the perfect mix of tutorial and reference, presenting an enormous amount of technical detail in a careful progression. Unfortunately, I can't say the same for their book Essential JavaFx: the material is disjointed, skimming the surface of many topics in seemingly random order, without truly examining any of them.

This book begins, as nearly all programming books do, with a simple “Hello, World” example. This part is, in fact, a little too simplistic: it walks the reader through specific screens and buttons of the NetBeans IDE. The actual program appears only as a screen-shot, without explanation of its structure. For a book that is targeted to an audience with “some previous programming experience,” this is disappointing: I want to see the program, not the IDE.

Chapter 2 attempts to remedy that initial surface treatment, by presenting a relatively complex example application. And it starts well, with a description of the way that a JavaFx application is built around a “scene graph,” and the admonishment to “think like a designer [...] visualize the structure of your application.” But then, it dives into variable definitions and control constructs, without so much as mentioning how they fit into the scene graph. And from there, the same chapter touches on accessing Java classes, visual effects, lazy expression evaluation (not identified as such), and animations &mash; a few paragraphs or pages for each, without explanation as to how they might fit together in an application.

Chapter 3 is a whirlwind treatment of the core JavaFx language. And there is a lot to this language: it is far closer to Scala than to Java, with influences from Python. Indeed, I could envision an entire book exploring the effective use of these core language features, perhaps even ignoring the GUI.

The subsequent chapters are much the same: quick hits without real content. Chapter 6, “Anatomy of a JavaFx Application,” is the closest that we get to a step-by-step tutorial, yet even here the Andersons forget their early advice: rather than starting with the application structure, they immediately create component subclasses, and only later assemble them into a scene graph.

In the end, I put the book down and turned to my IDE and “experiential learning.”


So, not so great a review of the book. But the language looks fascinating, and I plan to spend time working with it over the next few weeks. My first impression is that it might in fact be “the next big language” for the JVM: it seems to be a nice combination of strong typing, declarative configuration, and functional/object execution. I'm wondering if, like Java before it, JavaFx might be introduced to the world as a GUI language, yet end up as a language for server-centric applications.

3 comments:

Pete Michel said...

What are you looking at JavaFx for? Web or Desktop applications?

The one thing I really don't like about JavaFx is that it runs in an applet in the browser. Do you have any thoughts on the positives/negatives of that? Applets have been the root cause of many headaches everytime I try to work with them.

I've been working with GWT a lot lately and one of the things I like about it is that it runs as native HTML/JS and you don't have to worry about the user having/allowing a plugin to run in their browser. Of course, this means I have to deal with the various browser behaviors, but GWT does a pretty good job of hiding most of that.

kdgregory said...

I'm not quite sure what I'm going to do with it, if anything. Right now I'm still trying to figure out what is the language and what is the platform. I definitely like what I've seen of the language, but not sure if it can stand on its own.

Something else that I like -- although I may be imagining this -- is that it will simplify building mobile apps. I looked at J2ME a few years ago and ran away ... too many different phone profiles and subsets of both language and library.

Your points about GWT and applets are well taken, although I'm not sure that applets are that big a deal at this point (the biggest problem I ever saw was IE's almost-Java). Today, I think the Sun JRE is pretty much ubiquitous for people who have Java on the browser -- although I don't think it matches the distribution of Flash.

And neither Java nor Flash will run on the iPhone, which seems to be the biggest market for mobile apps.

Pete Michel said...

That's a good point about being a replacement for J2ME. Although the carriers are as much of a problem there with not having easily accessible market places. Seems like the iPhone/Android/WebOS path is going to be successful ways to deploy mobile apps. I don't have a lot of confidence in the carriers getting their acts together for the apps that don't fit into one of those languages.

With applets, not sure about this but last I checked Google Chrome doesn't support them. Not a huge market share (and probably arguable that users with Chrome probably have other browsers as well) but that is still 5% of users.