Problems and Opportunities

There's no such thing as problems, only opportunities

There may be people and situations for which this is true: tow-truck operators and plumbers come to mind. But for the rest of us, it's critically important to tell the difference — in fact, that is the difference: criticality. Opportunities are optional, problems aren't.

I'm not sure where the “no problems” slogan came from, but I suspect a half-asleep MBA student in ECON 101. In economics, there truly are no problems, nor opportunities either, only choices. But every choice has an “opportunity cost,” which, confusingly, is the net profit from the best alternative. If you (like many business students) don't think of the possibility that net profit can be negative, it's an easy step from cost to slogan.

Houston, we have an opportunity

In the real world, however, net profit can be negative. And when you're a quarter million miles from earth, with limited oxygen and electricity, the opportunity cost of the wrong choice is death. In the computer industry, we're not likely to face such drastic costs; but that doesn't mean we don't have problems.

JavaFx: What Niche does it Fill?

I've had fun playing around with JavaFx. I can't shake the feeling that it's in the same situation as Java was in 1996: targeted to a specific niche, but much more useful as a general-purpose language. Unfortunately, everything I've seen says that Sun (Oracle) intends to keep JavaFx in the RIA niche, a competitor to Flash and Silverlight.

And if that's their plan, here's my response: ain't gonna happen. Flash got to its position of ubiquity not so much because of technical merit, but because Adobe has mindshare among the graphical designers who are — like it or not — the arbiters of what goes on the web. At best, these people think of Java as “something to do with JSPs”; at worst, they think of applets (or more likely, negative folklore about applets, because they've never actually seen one). JavaFx is as likely to replace Flash as The Gimp is to replace Photoshop.

More important, Flash itself may not have much longer to run: there seems to be a strong backlash against plugins. Apple, with the iPhone and iPad, is the leading edge of this movement. However, the same attitude is showing up in desktop browsers, as you can see from the many pages describing how to make Java work with Chrome (I spent a half hour trying to get the latest Sun JRE to work with Chrome on Linux, but eventually gave up; call this statement sour grapes if you wish).

Instead, I think RIAs will be built with HTML (5) and JavaScript. This is, again, something very familiar to web designers. Most seem to go the route of raw HTML plus a library such as JQuery, but libraries the Google Web Toolkit and Yahoo UI will probably be more useful to the application (versus web) developer.

But, what about the mobile market? After all, the JavaFx tagline is “all the screens of your life,” and they've certainly made an effort to create one platform to span desktop and mobile applications. However, as you dig a bit deeper, you find that mobile device support is not quite ready for prime time: “Sun is working with Mobile Device Manufacturers and Mobile Operators to enable out of the box support for JavaFX.” What of the billions of Java-enabled handsets already out there? It appears that they're out of luck (although I haven't actually tried running a JavaFx app on, say, a Motorola RAZR). And, just in case you missed it, JavaFx will never find its way to the millions of iPhone users.

To wrap up: I believe JavaFx has a bleak future if it's confined to the RIA and/or mobile markets. But those aren't the only markets out there, and there's no reason that JavaFx has to remain confined. As I wrote when I started this blog, I like Java because it has a simple yet very powerful mental model, and the JavaFx language seems to have the same characteristics. It encourages a functional style of programming while still being object-oriented. There are, of course, other languages that do the same thing; Scala, for example. But those other languages don't have the Oracle marketing department behind them.

There's a lot of discussion about how Java is to evolve. But language evolution is a tricky thing. I could easily do without the mess that is auto-boxing; other people feel the same way about generics. And C has remained essentially unevolved since the 1970s, yet is still very useful (albeit in limited niches).

So I'll end with a question: will Java continue to acquire cruft, or is JavaFx the future?

JavaFx: Threading

If you're thinking of writing server-style applications with JavaFx, threading appears to be a problem. The first hurdle is that JavaFx programs run on the AWT event dispatch thread — which makes sense for a GUI. Unfortunately, server applications often run in a “headless” environment, and there are some AWT classes that shouldn't require a graphical display yet still like to throw if they don't have one. Which means that, if some of those classes are buried in the JavaFx runtime, you won't be able to run server applications period.

Assuming that you get past the headless issue, it shouldn't be too difficult to create a background thread (either by creating a thread directory, or via javafx.async.JavaTaskBase) and start a Java server application such as Tomcat in that thread (I say “should” because I haven't tried this). That Java application could then invoke non-GUI JavaFx classes, perhaps one that implements javax.servlet.Servlet, as I described in the previous post.

However, I think there are dragons lurking here. The only reason that you'd want to implement a servlet via JavaFx is to exploit language features such as data binding. Looking at the generated bytecode, however, I haven't found any synchronization and I've seen a lot of static members. In a multi-threaded environment like an app-server, this seems to be an invitation for data corruption.

I'm also somewhat disappointed at the threading support for writing GUI apps. As I've written elsewhere, long-running operations should execute outside of the event dispatch thread. The javafx.async package provides two ways to run such code: the first is JavaTaskBase, which as its name indicates, is meant to run code written in Java (and said code is not allowed to invoke JavaFx classes). The second approach is via Task, which is not terribly well documented (“does not define how to specify the code to run”), and appears to be meant for internal use by API classes such as javafx.io.http.HttpRequest.

Speaking of javafx.io.http.HttpRequest (which is not found in the provided src.zip): I ran the example provided in its class documentation, with the addition of printing the current thread for each of the callbacks it defines. And discovered that the callbacks were not executing on the event dispatch thread, so shouldn't be allowed to update GUI components. As I said, there are some dragons here.

On the positive side, when I look at the provided source code, I note that Brian Goetz (author of Java Concurrency In Practice) is listed in the @author tag for many classes. I can only hope that this association is ongoing, and that he gives some thought to JavaFx concurrency in practice.