JavaFX Script isn't in JavaFX 2.0 - what's the practical impact for working with JavaFX now?

from my JavaOne talk.

At JavaOne, it was announced that JavaFX 2.0 won't support JavaFX Script. (Or at least, Oracle won't be updating the JavaFX Script compiler for JavaFX 2.0.) Although Oracle had kindly given partners and speakers a little advanced warning of this, I met quite a few people at JavaOne who were taken by surprise. And at face value, the situation today is a little odd:

• JavaFX 1.3.1 requires you to write in JavaFX Script
• JavaFX 2.0 won't let you write in JavaFX Script
• (and 2.0 isn't out until next year)

And many people find themselves in a dilemma: Does that mean all code for 1.3.1 has to be thrown away? What do you do until 2.0 is available if you can't just "wait a year" -- 2.0 code can't be written yet but 1.3.1 code would be wasted?

After rejigging my talk a little, I inserted a few slides on what I think the practical impact on our project is in the short term. After all, my team has a JavaFX 1.3.1 client. How has this announcement affected us?

Well, the first thing to say is that even today a lot of a JavaFX client can be written in Java. I ran some rough line counts on our JavaFX client -- the client I demo'ed at JavaOne -- and it came up as:

• 27% JavaFX Script
• 73% plain ol' Java

So the impact for us is a bit smaller than it appears. Part of that is because I was very cautious about committing the client to JavaFX. JavaFX 1.2, which we had to cope with until April 2010, had some very awkward bugs in it -- and there seemed to be a lot of risk with the Oracle buy-out and JavaFX gaining little market-share. So I kept as much of our code as possible in Java, ready to jump ship from JavaFX if we needed to. The libraries, model, data handling, and most of the guts of our code aren't written in JavaFX Script but just in Java. And it seems that's just as well. I realise other projects might not be in that situation though.

So this seems to be rule 1 for working with JavaFX at the moment:

If a class doesn't have to be written in JavaFX Script, write it in Java, Scala, Groovy or some other JVM language. Save yourself the effort of converting it later.

Various talks at JavaOne described possibilites for working in a JavaFX-Script-like way in JavaFX 2.0:

• Stephen Chin is keen to get an open source project going to update the JavaFX Script compiler so it can target 2.0
• Jonathan Giles and Stephen Chin showed how code in Scala, Groovy, or Clojure can look very similar indeed to JavaFX Script

In my view, it's too early to assess whether it will be easy to convert non-trivial JavaFX Script code to Scala or another JVM language. The 2.0 libraries are still being written, and nobody has much experience converting non-trivial apps yet -- even some of Oracle's demos in Richard Bair's JavaFX 2.0 talk were still written in JavaFX Script code; they hadn't been converted yet. It should be straightforward -- the 2.0 libraries are supposed to contain all the functionality of the existing JavaFX, so it should just be a matter of converting syntax, not redesigning your client. But let's wait and see on that.

It's also to early to assess whether the open source project to update the JavaFX Script compiler will be successful or not. Again, it should be. The JavaFX Script compiler always compiled to Java, and under 2.0 it'll have some libraries to target that will be a very close mapping to its language features.

So what can you do now?

• JavaFX 1.3.1 is a production release. And it works pretty well. (Unlike, say, 1.2!) So in the short term, targeting an app at 1.3.1 isn't so bad.
• JavaFX Script is still very fast for prototyping. Many of our visualisations were written in hours, not days. If you are doing prototyping or scientific experimentation where the results and the design decisions are more valuable than the code, JavaFX Script is still a pretty good choice.
• If you do keep most of your model code in Java, then the JavaFX Script code you write will usually be fairly simple. That means it's going to be less complicated to convert to another language if you decide to.

For my project, in fact, JavaFX Script not being supported in 2.0 makes very little difference. Government-funded research projects get fixed funding periods, and our current funding round finishes before 2.0 will be released. So we couldn't target 2.0 anyway. (If our hospital partners' experiments are successful, and more funding is won to take it further, that'd come with more development funding to deal with productisation issues -- including upgrading from 1.3.1 to 2.0. We'll make that as easy as possible to do, but we don't have to pencil it into the calendar yet.)

Checked and unchecked exceptions in Java

Over on Stephen Colebourne's blog, there's a discussion on whether checked exceptions in Java were a bad idea.

It seems to me that if you declare an exception as being a checked exception, you're effectively making three claims:

1. You can't programmatically prevent this exception from occurring.
   Declaring checked exceptions requires you to put in code to recover from the exception.  It makes no allowance for code that actually won't ever cause the exception in the first place.  You can swear blind "No that can't throw a MalformedUrlException because I already know http://www.twitter.com is well formed", but the compiler will require you to catch a MalformedUrlException nonetheless.  (That trivial example could, for instance, be irritating if you've got a little throwaway app where you want to declare a URL as a static final constant.  The checked exception gets in the way even though it will never be thrown.)
2. You're so likely to forget to handle this case, and it is likely enough and serious enough to occur, that I'm going to force you to decide how you're going to deal with it right now ...
3. ... but it's not so terminal or abnormal that most applications shouldn't try to catch it
   (That's Error.)

Item 1 in that list makes me think checked exceptions should be rare.  Prevention is sometimes better than cure, but checked exceptions force you always to write a cure -- even if you've already prevented it.

But rare is not the same thing as non-existant.  Personally, I think File IO exceptions being checked is reasonable, for example.

JavaOne slides & Thanks for listening

I just wanted to say thank you to all who came to my talk today. Especially as I know there was a much higher profile JavaFX Graphics talk going on in another room at the same time. (Yes, that was a bit demoralising!)

I deliberately skipped some of the technical slides in the presentation -- this is because they are particular to JavaFX Script (deprecated in 2.0). The slides were the top few most hair-pulling bugs we came across in our JavaFX Script code. Things my team wished someone had told us before we started.

But to make sure you don't hit the same issues if you do any JavaFX Script, I have uploaded all the slides (including those) to Slideshare. The code examples should explain the problems reasonably well, and if not then please do ask.

Those slides are tucked in at the end of the presentation (91-106!). No, I didn't really expect to have time to show them -- when the 2.0 changes were announced, I thought it would be more useful to talk about the practical impact of the "death of Script", rather than talk about some technical traps in a language that's been discontinued.

Javaone

View more presentations from wbillingsley.

Things to expect in my JavaOne talk on JavaFX, OSGi, and the science of good (medical) conversation

Things to expect in my talk on Wednesday at JavaOne:

Wed 22nd Sept, 16:45 Hilton San Francisco, Golden Gate 3:
Visualizing the Science of Conversation with JavaFX and OSGi to Save Lives. William Billingsley, senior research engineer, NICTA
Session S313951

1. A JavaFX demo that isn't yet another video wall.  Not even wrapped around a big ball and rolling down a slide into yet another video wall.
2. The fastest, and hopefully clearest, introduction to OSGi.  We use OSGi on the client
3. A little commentary on the JavaFX 2.0 changes.  How to sensibly use JavaFX 1.3 given it requires you to use JavaFX Script and that's going away next version.
4. Programming as experimentation.  What do you do when it's actually a requirement that your requirements are unknown, and the goal of your software is to mine how your non-yet-users think.
5. What the picture below means, and why JavaFX on Mac finds it harder than a video wall.
   
   
   
   
6. How OSGi lets us build the great wall of science...
   
   
   
   ...how this picture knows what you're talking about...
   
   
   
   
   ...and how this one knows how hard you were thinking when you said it.
   
   
   

Science, JavaFX, and OSGi: appearing this week at JavaOne

On Wednesday, I'm giving a talk at JavaOne on how my team is using JavaFX to analyse and visualise medical conversations -- JavaFX in a scientific app, all pluggable and extensible via OSGi.

Wed 22nd Sept, 16:45 Hilton San Francisco, Golden Gate 3:
Visualizing the Science of Conversation with JavaFX and OSGi to Save Lives. William Billingsley, senior research engineer, NICTA
Session S313951

There have been a few lists of interesting JavaFX talks at JavaOne posted to Twitter and on the Web, and a few of those lists haven't included my talk. How to scare a speaker in one easy step: post a list of interesting talks on his topic and don't include his!

So, I just wanted to reassure anyone who's thinking of coming to my talk that yes it is on, and it should be relevant and interesting. (Or if it's not interesting, tell me off!)

A little later, I'll post more on what you can expect to hear at my talk.