New Job

Apologies for the recent blog silence for me. It's not that I've been slacking off. Quite to the contrary!
The biggest news is that I've changed teams: I'm now working on JavaFX! And more specifically, the designer tool.

If you don't know what JavaFX is, you're probably reading my blog because you're interested in Ruby, Python or the various other languages for NetBeans I've been involved with. If so, fear not - NetBeans language support is in great hands - Erno just improved the Rails dynamic finders code completion for Ruby for example. Of course, as an open source project we can always use more contributors! I've received a bunch of patches for the Python support recently which I've been happy to apply immediately. Keep 'em coming!

Briefly, JavaFX is a new UI stack for Java which makes it trivial to build pretty, dynamic and interactive UIs. While Java has always made it easy to target multiple operating systems, JavaFX makes it easy to target the completely separate platforms of desktop, web and mobile. If you haven't looked into it, you should.

JavaFX has its own language, JavaFX Script. It has some language level features which makes it really suited to building UI applications - from something simple like a literal for durations (so you can write 2m or 5s or 250ms in your source code), to something advanced like variable bindings which give you all of the power of traditional property change listeners, but without the pain (and it's more powerful than that - you can for example bind the rotation angle of a clock hand to an expression which computes the angle from the current time, and whenever the time variable changes the clock hand rotation is updated.) As a Java developer (and a Ruby and Python and JavaScript coder as well) I can truly say I've seen some things in JavaFX Script that I would like to see in other languages. I might talk about that in an upcoming blog entry.

If you're one of the alternate-languages-on-the-JVM people, I think you should seriously look into adding a binding layer for the JavaFX platform to your language. Libraries like Groovy Swingbuilders (and similar libraries for Ruby etc) have made Swing more accessible, but at the end of the day you're still dealing with Swing. If you want to add drop shadows, transition animations etc. a JavaFX DSL would be a much better approach. And besides, we're firing on all 256 cylinders on the JavaFX platform -- from the base Java platform (adding modularity so we can provide a barebones FX runtime), to the graphics system, to components, to the language, and up to the designer tool! I think it's going to shake up the RIA space - which is why I wanted to be part of it.

I promise my next blog entry won't be long in waiting, I've got a bunch of things queued up!


in other words: the JavaFX Designer is based on the NetBeans Platform ;)

>I think you should seriously look into adding a binding layer for the JavaFX platform to your language

yes a first class Java2JavaFX binding would be nice. :P

Posted by mbien on March 11, 2009 at 02:00 PM PDT #

I'de love to add a JavaFX DSL to Groovy and SwingBuidler, but the problem is the points we need to integrate into are either (a) poorly documented (javafx/java interop) (b) dismissed as an 'implementation detail' (scenario) (c) questionably licensed (what about net-disconnected deployment) and usually (d) all of the above.

The vibe I get from sun's official blogs and podcasts is that it is a 'take the whole stack or leave it' kind of thing. Which since I am one of those alternate-languages-on-the-JVM people makes it kind of hard to look into since JavaFX Script seems to be bolted quite solidly onto the stack.

So if there is room for a non-JavaFX Script alternative language in the JavaFX stack, I would be more excited about JavaFX. Does this signify a change from sun to help support that?

Posted by Danno Ferrin on March 12, 2009 at 02:57 AM PDT #

That is awesome news! JavaFX has a lot of rough edges right now, but the fundamentals look excellent and it's got loads of potential. Hearing that Sun is putting their top talent to work on the tools is very exciting to hear.

Posted by Mass on March 12, 2009 at 02:58 AM PDT #

Thanks for your comments!

Let me be clear that I'm not speaking in any official capacity - and also unlike my work on the NetBeans team, we're not developing the designer tool in the open so I can't really say anything about it yet - how it's built, what it will do, etc.

Danno, It's true that JavaFX script is a key part of the FX stack, in the sense that the scenegraph is implemented in it. There are various reasons for this; for example, if it were to have a plain Java interface you wouldn't be able to bind expressions directly on scenegraph elements. But it's possible to make calls into FX script today (use javap -c or jad to see what javafxc has compiled the script bytecode into) - the only disadvantage is that this can/will probably change in the next release since we don't yet have binary compatibility between FX releases. But the point is that it -is- possible to build and manipulate the stack from Java or other VM languages today -- JavaFX script is a statically typed language which just spits out bytecodes and calls into a runtime library, so your own VM language can spit out the same bytecode (again, use jad to see what fxc did). And yes, your point of javafx/java interop being poorly documented is true - I don't think it's supported today because the name mangling can and will change. But not forever!

Thanks a lot for your feedback!

Posted by Tor Norbye on March 12, 2009 at 11:14 AM PDT #


I think you have also mentioned one of the other reasons, and really the primary reason, I haven't been too serious about it: it is a moving target. So far there are three different incompatible versions of JFX: the preview, 1.0, and 1.1. And it is now promised that 1.5 will also have issues.

I do this stuff in my free time, and I am finding that I have less and less of it as my children grow. If I take the effort to make Groovy work with the FX stack I don't want that to be wasted effort. It looks like cool exciting stuff, but I hate writing code that I know up front will be thrown away.

Posted by Danno Ferrin on March 12, 2009 at 11:21 AM PDT #

Considering how much you helped with the success of NetBeans, this is certainly great news for the JavaFX team :)

Posted by Eric Wendelin on March 26, 2009 at 01:11 PM PDT #

Just a hint to "see" what javafxc (JavaFX compiler) is really generating behind, in form of Java source (instead of javap or jad):

When compiling, use the undocumented switch "-XDdumpjava" (a "dumpjava" sub-directory should be already created)

> javafxc -XDdumpjava \*.fx

Posted by El Cy on March 30, 2009 at 10:55 PM PDT #

Post a Comment:
Comments are closed for this entry.

Tor Norbye


« July 2016