Archives for category: General

51oS4qJWf8L[1]Hendrik Ebbers was generous enough to arrange for a hard copy of his new book, Mastering JavaFX 8 Controls, to be sent to my place, so the least I can do is post a mini review of the book. I have now read the book cover to cover and I think that it is a very good book for people wanting to learn more about the controls that ship in JavaFX 8, and also for people wanting to learn more about how to build custom controls specific to their use cases.

Reviewing a book like this is difficult for me as I have lived and breathed JavaFX UI controls for over five years now, so it is hard for me to gauge whether the book is detailed enough for people newer to the subject. My gut feeling is that the book could do with more text to describe concepts, but in general I think most readers should be able to follow along without a problem. In reading the book I made a few notes that I have also passed on to Hendrik, to help improve future editions of the book (which I hope there are as JavaFX API evolves quite rapidly).

The early chapters of the book give a good introduction to the basics of JavaFX. The middle section gives a good overview of the existing JavaFX UI controls, as well as interesting topics such as Swing and SWT integration, and styling UI controls. Unfortunately, whilst the first two sections feel like they go at a good pace, the final section of the book seems to be over too quickly – there is only one chapter on creating custom controls, which is unfortunate given the subtitle of the book is “Create Custom JavaFX Controls for Cross-Platform Applications”. It would be nice to see the final section of the book expanded to fill multiple chapters in future editions – this way it could feel less cramped and the book could easily become the go-to reference for how to create custom controls.

One nice aspect of the book is the interviews with members of the community (including myself). I enjoyed reading the interviews, but I wished for more and for them to be longer! :-) There are a lot of interesting members of the community who can provide a bunch of detailed insight and explanations, so I hope future editions expand on the interviews.

Overall I think that this is a great book for people interested in working with JavaFX UI controls, and shows great promise for future editions if some of the kinks above are worked out. Despite my negative points, I recommend this book to people who are serious about wanting to get to know JavaFX UI controls in greater depth.


At the JavaOne technical keynote just now Richard and Jasper introduced the DukePad – a custom built tablet device powered by a Raspberry Pi and featuring a touch screen, camera, HDMI output, GPIO pins, and more. It is powered with Java and has a custom-built JavaFX user interface.


The DukePad is a Do-It-Yourself, make-at-home tablet computer based on the Raspberry PI and JavaSE Embedded 8. The plans and instructions for building the DukePad are available here, and we’re working with suppliers to make available pre-made kits that can be more easily assembled. The software on the DukePad uses Raspbian Linux as the operating system, and an OSGi-based JavaFX environment. Within this DukePad environment, apps are simple JavaFX OSGi Modules.


Click for bigger image

The DukePad is not a product, it is an open source, freely available set of plans and software for assembling your own tablet using off the shelf components. As such, the quality of the DukePad software environment is demo-quality (although we did strive to write as much real functionality as we could, the realities of demo presentations requires sacrificing time on parts of the applications that are not going to be shown, in favor of smoothing out those parts that will be shown). The code is hosted in the OpenJFX repositories under apps/experiments/DukePad. We hope to see forks of this code (GitHub, BitBucket, whatever you like best) and lots of experimentation and improvement that can be shared.

One of the big features I’ve known people have wanted for a long time (hey, I’ve wanted it too!) is support for returning a TableView back to its original, unsorted state after being sorted by the end user. In general the user interaction goes something like this:

  1. Click on a TableView column header once. Everything sorts in ascending order. Great!
  2. Click on the same column header again. Everything sorts in descending order. We’re on a roll here!
  3. Click on the same column again. The sort arrow disappears, and…….nothing :-(

Of course, what should happen here is that the order of the items in the table should be reset back to their original order, from before the user ever clicked on anything. If you step behind the curtains with me for the briefest of moments, you’ll realise that the only way we can really do this is to of course keep a copy of the list in its original state (or a list of all the changes to the original list, such that we can unwind the changes later on). I never really wanted to do this, as you’re just setting yourself up for failure / pain / bugs / etc. What I always wanted to do was follow the wonderful GlazedLists approach from the Swing days, where the collections themselves became smarter, and the TableView remained mostly* inconsiderate of the type of collection given to it.

It’s been almost 2 years since we released JavaFX 2.0 on Windows, followed by Mac OS X and Linux support, and plenty of new features. It has been a blast for us, and we’re pretty happy with what we’ve accomplished so far. JavaFX 8 (JDK 8) is looking in great shape, and we’re pretty much done open sourcing all of JavaFX through OpenJFX. However, nothing matches hearing from you and getting a pulse on the developer community.

So, it’s time for another survey on FX Experience! You may recall our last survey was about tablets and mobile support, and we received an absolutely huge number of submissions. That information was fed directly to the relevant people, and they’ve asked us again to put out the survey below. Your input is hugely appreciated and it is a great way for you to continue to influence the future of JavaFX! Get your friends to participate! :-)

We’re running a little survey here at FX Experience to get input from JavaFX developers (and everybody else!) as to the ways they would use a port of JavaFX to smartphones and tablets (think: iOS, Android, and WinRT). This is your chance to really influence the future of JavaFX! Get your friends to participate!


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: