Update: since announcing the JavaFX UI controls sandbox I have announced the ControlsFX project, which is a more convenient way to get access to a number of controls that do not ship with JavaFX. Check out the ControlsFX website for more information.
This is something I’ve been waiting a really, really, really long time to announce, but it has finally happened. Today I am so pleased to announce the opening of the JavaFX UI controls sandbox repository on OpenJFX. This repo is a fork of the JavaFX 8.0 controls repo, but will occasionally sync from there to keep it up to date. This repo is intended for OpenJFX developers to put their ‘toys’ until such time that they get called up to the big leagues for inclusion into OpenJFX itself (although there are no guarantees that this will ever happen). This means that the controls are functional, but most probably not feature complete with a finalised API or any significant documentation.
The reason why I’ve been wanting to open this sandbox up is so that members of the JavaFX community can get super early access to our controls as soon as they reach the most minimal level of maturity, and help guide them along their paths to adulthood. I also wanted to do this as it takes a long time between developing a UI control and having it appear in a JavaFX release. This is something that has frustrated me, and a number of you, to no end.
From the get-go there are a few controls in this repo that you may be interested to play with and give us feedback on. They are TreeTableView (although note this is currently undergoing a total rewrite), Dialogs (ala JOptionPane from Swing), TableView cell span support (look at TableView.spanModel for more info), and a RangeSlider control. These controls will develop over time, but of course we’re always on the lookout for others who want to improve these controls for us. If you’re interested specifically in tending to the new controls in the sandbox, please email me and we can discuss it.
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.
Update: More recent releases of Scenic View have been released since this post! Go to the Scenic View page to download the latest release!
Developing user interfaces is tricky, regardless of whether you’re just trying to understand the high level scenegraph layout, or whether you’re pushing pixels for a finely tuned user interface. I understand and feel for people in this situation. UI developers come up with all kinds of tricks, for example, temporarily introducing a bold one pixel border of varying colours around components to better understand the user interface. I certainly know I have done that countless times in the past when building user interfaces, and frankly, it is painful and massively time consuming.
Inside the JavaFX team, since times of yore (that is, since at least JavaFX 1.3, but perhaps earlier – my memory fails me here), we’ve had this remarkable little tool that was called Scenic View. It somehow just burst into existence, through the brilliance of Amy Fowler, whom many should know as the layout guru for both Swing and JavaFX. Scenic View is a tool that can be called to browse a live view of the application scenegraph. Here’s a screenshot:
I came across the interesting blog “JavaFx and HTML5 differences” by Chika Okereke. Looking at the example code and comparing to the HTML Canvas version I thought the Java code could be made less verbose and easier to read.
Path path_4 = new Path();
ObservableList shape_4 = path_4.getElements();
So I hacked together a Extended version of the PathBuilder that ships with JavaFX 2.0 adding methods for all of the path elements like moveTo() etc. The end result seems much cleaner code to me, what do you think?
Code with new Builder
Path path4 = PathBuilderExtended.create()
This seemed a lot cleaner and simpler to read. I have filed a feature request RT-19266 in JIRA to add this to the platform. Feel free to comment on the bug if you any feedback or better suggestions. Also I have attached a implementation of this builder to the bug so you can see how it would be implemented or use it with your code today.