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.
Something that you see more and more with client applications at the moment is embedded map components. This blog will show you how to embed Google, Yahoo or Bing maps in your JavaFX application.
Google Maps in JavaFX 2.0
Download a copy of the application and try it out. The jar file is linked below, just download it and double click. This requires you to have the JavaFX 2.0 beta runtime installed.
We did a complete rewrite of charts in JavaFX 2.0 to add cool features like:
There is a sample application called “Chart Sampler” that ships with JavaFX 2.0 Beta that shows some of what can be done with the new charts. Here are a few screen shots to tempt you to go and check it out 🙂
(more…)
For months and months we’ve been focused solely on the mechanics of building a platform — API design, writing tests, fixing bugs, use cases, features, documentation etc — and with the release of the beta the #1 question on everyone’s mind is, “Is JavaFX 2.0 cross platform?!”. That the beta is initially a windows-only beta has apparently stirred up a fair amount of concern. Shockingly, some people have even asked whether we ever intend to be cross platform. I can say definitively “Yes, of course!”. It would be quite illogical for any platform released by the Java team to not be cross platform. And even more so for the Java team to release a platform which had no intention of being cross platform while also purporting that the said platform was to be the next generation Java rich client platform.
We absolutely will be targeting a whole host of different platforms, not even just the big three (Mac, Linux, Windows). The value of the Java platform is in the fact that you can write across multiple operating systems and devices.
Now, somewhat like Apple, Oracle doesn’t tend to make premature announcements. I cannot at this time comment on when support for different platforms will be available, but hope to comment when such announcements have been made through the official channels. I know that this form of communication strategy leaves people to their own imagination which, as often as not, seems to be rather pessimistic in nature :-). So, to help provide some guidance here, I’d just like to say:
JavaFX will be cross platform.
Great news today, the public Beta for JavaFX 2.0 has been released! The beta includes a handful of samples, including Ensemble which is the sampler for JavaFX and will be beefed up over time to include tips and tricks and other such things. There is also javadoc (though, beware, there are still JavaFX Script examples. The docs for new code is better than old code). If you find bugs, submit them to the JavaFX JIRA bug tracker.
There is a lot of great stuff in this release, including binding, observable collections, sortable and filterable observable lists, many more UI controls, enhanced animation support including for game loops (AnimationTimer), properties (observable!), and more. There are a few things we’re still adding (including some important things!), but for the most part, the features are all there and functional, so go try them out! Please do file bugs, write blogs, and let us know what you think of the APIs. Things are definitely more verbose in Java than they were in JavaFX Script, though in large part this will be solved with lambda’s in Java 8.
Especially, if you have use cases that our APIs prohibit (as opposed to API we just need to add) please please please! file these in JIRA! The reason we’ve released the beta is to get exactly this kind of feedback. API is forever, so all the feedback you have on the API please file, and the sooner the better!
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.
Gluon offers industry-leading solutions for mobile and cloud, as well as professional Java and JavaFX consultancy.
FX Experience is maintained by Jonathan Giles.
