One of the questions asked in my JavaFX 2.0 blog post, and also at my second JavaFX 2.0 talk on Thursday at JavaOne was around Swing integration for JavaFX 2.0. I wanted to clarify what my current thinking is, and give you a chance to respond.
Edit: If you haven’t yet, please go read Amy’s heartfelt ramble on swing and javafx. She’s says better (and with more authority, having been a critical engineer on AWT, Swing, and JavaFX) than I did.
Over the past several years as I’ve gone on customer visits or to conferences such as Devoxx, I’ve heard repeatedly and clearly that people want to be able to use JavaFX in their existing swing applications. This is obviously important for anybody who has a big, existing swing application or is planning on building a new application in Java and has chosen swing.
In the JavaFX 1.x platform line, we’ve supported the ability to embed Swing components in JavaFX applications. This, however, is not generally that useful for people with existing Swing applications, but rather for people writing new JavaFX applications. This ability has been crucial if they wanted to have rich text or tables or combo boxes. Basically, it acted as a patch to allow JavaFX apps to be built if there weren’t equivalent JavaFX UI Controls yet built. But it wasn’t a bridge per se.
It also isn’t supported in the new Prism pipeline.
However going the other way and allowing JavaFX to be embedded in Swing should be quite feasible, even for the Prism pipeline. Which gets to another point — why having Java APIs for JavaFX was so important.
While on the train to the first Devoxx after JavaFX 1.0 was released, Jasper and I whacked together a quick proof-of-concept implementation of a Swing component that could host a JavaFX Scene. It was subsequently released by Josh Marinacci and some other implementation (I’m not sure if it was ultimately based on what Jasper and I did) was taken and released as part of JFXtras.
The problem with this has been that you cannot reliably modify the JavaFX scene from Java code. This is because the JavaFX Script compiler would produce “obfuscated” java code (this is actually a huge oversimplification and not quite technically accurate, but correct in the essentials). Instead of the mutator for the “x” property being setX, it was set$x. But of course what it was actually called and how it actually worked was subject to change from release to release so you couldn’t dependably talk from Java to JavaFX Script except through interfaces — it was all quite cumbersome.
So to enable developers to embed JavaFX inside Swing is a two part problem: how to do it at a graphics engine level, and provide clean Java APIs for working with JavaFX.
Now that we’ve announced the latter, we’re ready to start working on the former. There are, as you can imagine, a lot of details to sort through. For example, do we force 2D rendering when embedding in Swing? That would certainly be the easiest thing for us to do, but also the least glamourous since you wouldn’t get all that nifty hardware accelerated 3D stuff we’re talking about.
We may instead try to do something along the lines of what Java3D and JOGL did — essentially embed a heavyweight in the swing app. We’ll have to work through problems that may arise when Java2D is using DirectX and JavaFX is using DirectX. We’ll also have a whole pile of thread related issues to sort through.
Speaking of threads, one of the main design goals for JavaFX was to separate the UI thread from the rendering threads. This would allow us to take advantage of all those wonderful cores on machines these days for rendering without slowing down event response times etc. However, Swing was designed such that the UI thread *was* the rendering thread (another problem with immediate mode rendering APIs).
I guess I haven’t quite recovered from JavaOne yet. Rereading this blog post it rambles a bit. So I’d better just stop :-). In Summary, the current plan of record is to work towards allowing developers to put JavaFX content into Swing applications (WebView, Media, scenes, animations, etc), but perhaps not the other way around.
Yesterday morning at JavaOne I gave a presentation called “JavaFX 2.0” (which will be repeated Thursday afternoon, and again October 5th at the SVJUGFX). There were several announcements both in the talk and in Thomas Kurian’s JavaOne keynote last night as well.
Yesterday we announced the roadmap for JavaFX 2.0. If you haven’t read through it yet you should stop now and go over and read the roadmap. There are a fair number of features going into JavaFX 2.0 and we’ve identified which will be available for the early access (EA) build, the beta build, an the final general availability (GA) build. There are some really great things on there such as fully hardware accelerated graphics pipeline (Prism), High-def media, a TableView control, CSS animations and layout, and much more.
In general, JavaFX 2.0 is a continuation of JavaFX 1.0. There is, however, one big change and that is with the language. JavaFX Script won’t be updated by Oracle for JavaFX 2.0 to run on that platform. Some folks in the community have expressed interest in taking on this task themselves — and I wholeheartedly encourage this. The JavaFX Script compiler is already open source. We haven’t worked out the details but I would imagine we’d rather add community members as owners of the project than have it fork.
Up to this point the only language that could be used to build JavaFX applications was JavaFX Script. I always felt this was a needless restriction. In addition, I felt that it was actually a bad thing for JavaFX Script the language for a couple of reasons. First, since all our APIs were in JavaFX Script, it meant that JavaFX Script had to be changed to be a good language for writing APIs, whereas it was originally designed to be a good language for scripting UIs. Sometimes this created a design tension. The compiler guys very wisely kept the focus on scripting UIs instead of writing APIs (which is why JavaFX Script was productive to use for building UIs), however it made our job on the platform team more difficult.
In addition, since the entire platform was built on the language, they didn’t have the freedom to fix certain issues in the language (such as initialization, which admittedly was mostly a problem for folks building libraries). My feeling is that decoupling JavaFX from JavaFX Script frees the language so that it can continue to evolve. Most languages have years to mature before becoming stable. JavaFX Script had a few months. It is to the credit of the compiler team and Brian Goetz especially that it came out as well as it did in the end.
So even though Oracle itself isn’t going to be committing to updating and shipping JavaFX Script in the JavaFX 2.0 timeframe, I sincerely wish to see it continue to evolve and improve. The same Binding capabilities that JavaFX Script enjoyed will be exposed as a library in Java, so any updated JavaFX Script compiler will have the tools it needs to implement language binding. Also, we’re working on the initialization issue such that object literals will still be possible (we’re considering several forms of initialization including the builder pattern).
In addition, I’m very excited to see what other languages can do / will do. Charles Nutter tweeted “Perfect storm: Mirah plus JavaFX APIs.” (Sorry I’m not a very good twitter person, I’m not sure how to link to the tweet!). I couldn’t agree more, I’m very interested in what Mirah would look like for building UIs on JavaFX. Especially if a variant of it could support bind in the language (which would be incredible). Already JRuby and Groovy work quite well with our current Java-based APIs.
Of course in the world of soundbites, what we see is “JavaFX is dead” (which is obviously not the case if you have seen any of Thomas Kurian’s keynote from last night), and “JavaFX Script is dead” (which is also not the case — it is open source and many of the strongest proponents have been in the community).
JavaFX is core to the strategy for rich client application development at Oracle. Simply put, JavaFX is the evolution of the Java rich client designed to address the needs of today’s and tomorrow’s customers. This is all about making Java dominant on the client. Jasper will post some videos of actual live demos we ran on stage at JavaOne (I hope he gets it up on youtube so it will be viral. Apologies if we use a flash player… for now!).
We have a lot of work to do. I think there will be critics and doubters along the way — but that’s fine. I welcome that. Judge us by what we ship, not what we say. I think JavaFX 1.3.1 was a great release (all of the stuff Jasper is showing in his demo is achievable with the APIs in 1.3.1 + the media and prism implementations for JavaFX 2.0). I’m really looking forward to delivering the next version of JavaFX.
Finally, we’re hiring! I’m looking for people who are talented, passionate, and have a good attitude. We have put together a really great team with a great atmosphere and we’re committed to engineering the best platform. If you think you’d be interested, drop me a line. We have positions in UI Controls, text, graphics, media, deployment, management, and more. Just drop me a line at my oracle email address and I’ll forward your info along into the system.
A slightly early post this week, as the normal post date coincides with me being enroute to San Francisco and JavaOne. Therefore, not as much news as usual – but I’m sure there will be plenty of JavaFX news in the next few weeks to make up for this. Enjoy 🙂
That’s it for this (short) week. Like I said last week, I’ll try to do a post whilst I’m overseas, but no guarantees 🙂
The final week of JavaFX desktop links before JavaOne, and bucking the trend I mentioned last week, there has been a heap of posts this week. Let’s get into them!
That’s that for another week. I’m not sure when the next post will be as I’ll be travelling to the US for two weeks next weekend. I’ll try to put something out, but I’m not sure when 🙂
Wow, it’s September already! This year is flying by, and JavaOne is right on the door step. This week there is a bunch of interesting news: let’s get right into it!
That’s that for another week. I hope you found a useful link or two. Catch you all again next week 🙂