FX Experience Has Gone Read-Only
I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!
tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.
by Richard Bair | Sep 24, 2010 | General, JavaOne
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.
by Richard Bair | Sep 21, 2010 | General, News
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.
by Richard Bair | Jul 6, 2010 | Tips n' Tricks
One of the annoying sharp edges in JavaFX is around text alignment, especially with regards to the Text node. In this tip, I’m going to skip using the Text node in favor of using the Label control, because it gives you better… uh… control over text placement. This is actually based on a trick I used to use with Swing all the time. If I wanted to center some text in a layout, I’d specify the space I wanted the text positioned within by setting the size of the label to match that space, and then I’d either position the text at the center, top, right, etc.
Using the same trick in JavaFX, I can cause some text to be right positioned. An additional benefit to using the Label control is that if the space isn’t big enough for the text, it can be elided using the textOverrun variable.
Label {
width: bind 120
text: "Right Positioned Message!"
font: Font { size: 10 }
textFill: Color.BLACK
hpos: HPos.RIGHT
}
Anyway, it ain’t perfect but a good trick for the moment.
by Richard Bair | May 28, 2010 | Tips n' Tricks
I was going through my bug list today and noticed this bug, Document how to embed fonts in FX apps. A quick google search turned up a single forum posting on the subject which just linked back to the root bug (lucky for me I put the solution in the bug report so people weren’t completely stuck). Surprisingly, I couldn’t find any documentation on the subject here at FXExperience.com, so I thought to rectify that with a short post explaining the subject. (more…)
by Richard Bair | Apr 27, 2010 | Controls, Tips n' Tricks
One of the really neat things about the JavaFX ListView control is the Cell API, and the ability to have dynamically variable row heights, without sacrificing performance or scalability. To accomplish this, we’ll write a custom Cell factory which will create a Cell who’s size depends on some state.
To recap briefly, to remain scalable and fast, the ListView reuses Cells for rendering each row in the ListView. Because it reuses Cells, each Cell needs to be designed so that it does the right thing no matter what row it is asked to represent — even empty rows which are used only for filling out a ListView and not for actually holding valid data. (more…)
