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.
If this is achieved – it will be fantastic and will gain the respect of the enterprise community. I am one of those people with a large Swing app that has been dying for the ability to integrate FX (with a longer term view to replace).
Since the announcement I have wondered about Prism and AWT “cohabiting” and will be very interested to track the progress/design/approach – I hope it will be as open (as it can be) and we don’t have to wait long periods before finding out details. As you mentioned there is certainly some interesting/challenging/exciting details to work through
sign me up for the alpha 🙂
Hi Richard,
This week I intend to release a beta of my app (Modellus), it is a swing/javafx app which uses my JXScene implementation (with the precious help of jfxtras members) available on jfxtras.
Yes the other two implementations JXScene for javafx1.2 and JXScene for javafx1.3 are based on your, and Jaspers work.
I can’t help but feel sad that javafx script is out. I’m now caught up in a limbo, not knowing what to do until javafx next release which will only be available in a year. Since the project can’t wait that long this is a tough situation.
I hope i do not have to switch to other technologies.
Cheers.
I always asked myself why JavaFX hasn’t done that since day 0. (obviously, they must have been non technical reasons for that)
JOCL/JOGL maintainer
Looking forward for that mutation :integrate Fx component into Swing panels.
I am praying for that everynight since 3 years ;)…
In my opinion this is just a continuity, just a respect of the java guys i guys like me.
Was it true that some people at Sun believe we had to rewrtite all the code. Just to please them ? Na ….
Obviously we now have a clear issue when integrating JavaFX and Java. But I’m not totally sure that getting rid of FX script is the answer I was expecting…… Having a clean Java interface to an FX component is necessary, but does that really mean that FX script must be replaced by pure Java ? It looks like we will have to switch to another technology anyway (Scala, JRuby, ….) as writing components the “Swing way” is definitely not very efficient ( I do not mean that it is bad, but just not as efficient and readable as FX script).
Now one critical issue that I came across was not to much related to the fact that I could not access javaFX components from java, but more on the way javaFX render the components (and, maybe I’m wrong, but it does not seems to planned to be fixed). I wanted to integrate an external video player in our javaFX application (as the standard JavaFX media player is definitely not up to the level). The fact that javaFX does not provides an heavyweight canvas was a show stopper: I had no way to display the video inside a javaFX application.
Instead of making it possible to integrate JavaFX in Swing, I believe it would be much better to put all efforts on migrating the NetBeans Platform from Swing to JavaFX as soon as possible: a NetBeans Platform in JavaFX = no more reason to stick to Swing!
Thanks for the honest blog Richard and for the talks at JavaOne. For my part I am _so_ glad that it is going to be part of the core Java language.
There, I saw your examples of JavaFX depicted as Java code, but what was absent (unless I missed it) were all the interesting stuff: how to do a bind, triggers on properties and functions (or methods?), a bind to a function — you know, the things that made JavaFX the bomb. Seriously, those syntactical innovations were clearly best-in-class of any language out there. Concise, readable, to the point — and of course built-in.
Oh please do say that you are going to introduce a bind keyword and a trigger keyword in Java. Yes, I do know that this is a seriously big deal and that I’m asking a lot. If you give us that, I think building up a scene graph in a non-declaritive fashion won’t be too bad. We can always load up a DSL and do a joint compilation like one does with groovyc or scalac -d.
Whaddya think, can you give a less trivial example or is it too secret still (and I will understand if you can’t; there are doubtless really good reasons if that’s the case)? Are you going to make us use annotations to do the magic (not that that won’t be better than what we have in plain Java today)? Surely for the next generation of Java — and to be competitive — we need the innovation of JavaFX syntax.
Since I am also rambling — may I offer strategic advice? Put your work in the JDK/JRE. You’ll get adoption. People will trust you because we all know that nothing gets dropped once put in there. But maybe after a version or two. 🙂
My two, or three or four, cents.
-Pupmonster
When you say you might embed a heavyweight into the app…does that mean you are considering having the equivalent of what is a JInternalFrame be a heavyweight component and support drawing to it while at the same time drawing to another Jinternalframe in the same container, while both of the components may overlap each other?
I really like that. Because of some of the images I create can be quite complex/time consuming to render it is imperative that the user can see them ‘drawing’ in the multiple panels at the same time and be able to interrupt them to make feature changes.
I had to implement this myself because of the lack of support in swing for heavyweight components and threaded drawing. I would call it a poor mans threaded drawing solution where what I want is one supported by the api and let me get back to application programming.
Is there any more information on this subject that I may be able to get at?
thanks