Say what!? JavaFX 8.0 is on its way? Sure enough! But first, by now you’ve probably seen the announcement that JavaFX 2.2 has been released (GA downloads here). A lot of highly anticipated features have made their way into this release, including a Canvas node similar to the HTML Canvas in that it lets you draw in an immediate mode fashion. We also added the ability to take a “snapshot” of some portion of the scene graph into an image. And we’ve added writable images, such that you can either modify the pixels directly or use AWT BufferedImages via the swing.ext package and convert them to JavaFX images. There have been tons of other additions and enhancements which we’ll be covering in the coming months.
Another major announcement as part of Java SE 7u6 (which was co-released with JavaFX) is that you can run JavaSE Embedded for free on devices such as the Raspberry PI. Up until this point you always needed a license to run on ARM, whereas starting with 7u6 the license allows for individual use on Raspberry PI etc. I’ve got my PI handy and am busy hacking away on it, along with the BeagleBoards and PandaBoards we’ve got en masse.
We’ve been doing tons of performance work recently, with all that work going into the 8.0 repository. Speaking of which, because JavaFX is being co-bundled with Java 8, we’ve decided to skip a few numbers in our version scheme to catch up. So the next major release (formerly 3.0) will actually just be called JavaFX and share the version number of the JRE that it ships with. If JavaFX becomes part of JavaSE in JavaSE 9 timeframe as we hope, then it would clearly no longer have its own version number, so it made sense to us to get in line now.
With that, I’m going to have to sign off and get back to performance hacking!
Igor Nekrestyanov yesterday wrote a very important blog post on native packaging for JavaFX applications. Some of you have tried out and commented on our previous blog post about FX Experience Tools, which used native installers. The jfxtras project has likewise created such native installers. The native application bundle approach to deployment is a new mechanism that we’re rolling out for both JavaFX and hopefully in the near future also for Java SE applications (such as Swing and AWT).
I’m going to do something today that I almost never do, and that is discuss briefly some of the bigger picture trends that I see widely in the industry, and discuss some of the things we’re doing but haven’t really talked a lot about yet.
At Sun, we would regularly talk about everything we were working on. Everything. Whether it was fully approved, funded, strategically relevant, or not. We’d just sort of throw it out there. Which was wonderful and liberating because we could just sort of say anything. And it was awful because nobody knew what they could trust. We’d announce something, work on it for a while, find out it didn’t really work out right, and then bail on it.
At Oracle, we don’t do that. We pretty much keep things quiet until we’ve lined up everybody — Management (which pays the bills), Product Management (which aligns the strategy), Engineering (who says what can or cannot be done technically or feasibly), Sustaining (who has to support whatever it is we do for the next 10 years or longer), SQE (who has to be able to test whatever it is we’re doing), and so forth. Once we’ve got each of those groups aligned with a strategy and roadmap that we are all confident we can execute on, and which we’re confident we can support for the foreseeable future, then we make an announcement. And of course we talk a lot with partners to find out what they think about the strategy and whether it makes sense to them. As often as not, we will make the announcement with some functioning code available that you can download and get started with.
You’ve seen this pattern for the last couple years in the Java and JavaFX groups after the Oracle acquisition. By the time we’ve made an announcement, we’re fully committed and usually we’ve got code to back it up. More often than not, we’ve got a Developer Preview or Early Access or Beta ready to go and we’ve actually been working on it for a while. This makes sense, because engineering can’t always ascertain feasibility without at least some kind of prototype. And we have now built up a track record of delivering either on time or ahead of time whatever it is that we commit to.
This has been a very conscious decision. Those from Sun, and those from Oracle, both knew that Oracle was going to have to prove itself as the steward of Java. We needed to execute continuously for several years to build trust with developers that when we say we’re going to do something, for goodness sake, we were going to do it.
And that is why we haven’t made any official announcement about Metro tablets or Android or iOS. And that is why I’m not going to make any official announcement in this blog post :-).
At various times people have written articles or blog posts or forum posts asking the question, what is JavaFX? Is it a competitor to Flash? (The answer would be No, though competing with Flex would be a Yes). Is it a competitor to Silverlight? (The answer would be Yes, for some use cases). Is it a replacement for Swing? (The answer would be an emphatic Yes).
I think at its heart, JavaFX is about application development. Good old fashioned native application development. The sorts of things you see in the iOS app store, or Android app stores, or that you install on your desktop. Think money management, banking, data visualization, entertainment, data entry, etc, etc. It isn’t competing with the web, unless you also think that native apps are competing with the web (in some sense, yes, but in a larger sense, no). The Web, to me, is two things. First, it is a medium for “browsing” or “surfing” data and information. And for that it is unparalleled. It works really, really well. Second, it is a distributed client/server architecture — REST. And that part of the web is used both by browser apps and by native apps. Pretty much every application worth anything these days has some web component, in that it is talking to the cloud using REST like principles and architecture for web services.
Hello from JavaOne Japan, where Jasper, Jonathan and I find ourselves seated in the opening keynote of the morning. One of the big announcements is the public beta of the JavaFX Scene Builder, our new tool for laying out and creating JavaFX content. The Scene Builder is the start of a more comprehensive RAD (rapid application development) tool for JavaFX, with drag-and-drop GUI building and eventually data binding.
Yesterday our SQE (Software Quality Engineering) team pushed our JavaFX functional test suite, JemmyFX to OpenJFX! They also pushed some tests for Ensemble, our samples application. JemmyFX is based on Jemmy, a visual testing framework for Java used in NetBeans for many years. JemmyFX contains extensions which make it possible to write visual tests for JavaFX. Although JemmyFX is in the openjfx repo, you can download it and use it for writing visual tests for your own JavaFX applications.
For those folks who have been looking at contributing code to JavaFX, this is great news, because it means you can accelerate adoption of your specific features by also writing the tests necessary to ensure correctness, either as JUnit tests or now as functional tests using Jemmy. All you guys working on DatePicker, I’m looking at you 😉