Archives for category: Uncategorized

More days. Much work. Such links. Wow.

Catch you all again next week! :-)

Here we go all over again! Enjoy! :-)

Catch you next week.

I am presently typing away on a new Retina Display MacBook Pro, and it is an interesting experience. The visual clarity is stunning. It is akin to the feeling of going from Atari to Nintendo, or Nintendo to Nintendo 64, or standard def to Hi-Def. I just didn’t realize what kind of poor quality I was looking at before.

But it isn’t all rainbows and sunshine. All of Apple’s applications look stunning. But many 3rd party apps look bad (including Java apps), and web browsing is horrific. The problem is high-DPI, and how Apple went about solving the HDPI problem.

On Retina MacBook Pro displays, there are some 220 pixels per inch. If you rendered everything 1-to-1 on such a display, the text (and everything else) would look tiny. You’d need a bionic eye (or a magnifying glass) to read anything on the screen. Or at least, really young eyes. So instead, everything needs to be scaled up.

For vector graphics and text, this is pretty straightforward. You just scale things up and render at the higher resolution and things look great. But for images it isn’t so simply. Scaling images produces a blurry result. And that, in fact, is the experience of using a retina display when browsing websites. You will come to some websites where the text is crisp and the images are all blurry. Other websites have some crisp text and some blurry text, ostensibly either because intentionally or unintentionally the web site is rendering text to an image and then the image is being scaled. And it makes for a horrendous user experience.

In Apple’s applications (starting with the iPhone and iPad with their retina displays), the solution to the problem is for the application developer to supply two images instead of one for each image asset. For example, the splash screen will be supplied with two images, one at normal resolution and one at 2x the resolution. The files are named the same but the 2x one is named according to some convention, such that at runtime the platform will lookup the 2x version on retina behind the scenes. In such a way, your application says “fooImage.png” but “fooImage@2x.png” is looked up instead when on a machine with a retina display.

At the moment, all Java applications (including FX) are pixel-doubled, such that everything (text, images — everything) are doubled and look blurry. But since I’m going to be working on a retina MacBook for the next several years, we’ve got to fix this situation. Driving me UP THE WALL. Our plan is to follow Apple’s lead, and automatically attempt to load the @2x image if one is available, and to otherwise signal to Mac OS X that we’re a high-DPI aware application and it shouldn’t pixel double everything on us.

One thing to be aware of here is that Canvas and ImageWriter are not going to be able to deal with high-DPI right off the bat. Your application is written as if it is on a normal display, but Canvas ends up needing to be pixel doubled. In the future we’ll add API so you can detect this situation and draw into a larger canvas (or automatically scale everything up for you).

I can’t wait for FX to be in hi-res!

After a ton of work and navigating the legal bureaucracy, Scott Kovatch on the JavaFX team has successfully put the first JavaFX Application (that we know of) into the Mac App store! It was particularly fun to read James Gosling’s ringing endorsement. As most of you probably know, Ensemble is our sampler application which has all the Javadoc and a hundred or so samples of everything from animations to controls to binding to 3D. It is also the application we will continue to build up as we go along. We originally released it with JavaFX 2.0, and the team has been adding content to it ever since (thanks Debbie! thanks Prague! thanks team!).

Getting it into the Mac App Store is a big deal. We first added support to produce native app bundles earlier this year, such that any JavaFX application can be co-bundled with the JRE to create a platform specific app bundle — a MacOS X .app and .dmg, for example, or an .msi and .exe for windows, or .deb / .rpm on linux. These app bundles are inherently secure (since they don’t rely on remote code execution, unlike Applets and WebStart). They also are completely “normal” for the end user. And they’re the only way to get apps into an App store. Oh, and since Java is co-bundled, these app bundles do not require Java to be preinstalled — so no more headaches dealing with what version of Java is installed and redirecting to install a specific version of Java. It all just works.

So go ahead. Build your desktop applications with JavaFX, and deploy to the Mac app store. You’ll be glad you did ;-)

I was inspired by Dean Iverson’s tweet with a audio equalizer in JavaFX:

#JavaFX rocks. Literally. An example from our upcoming Pro JavaFX 2 book:
and the equalizer view from that Pro JavaFX 2 example app:
. updated

So wanted to have a go at doing one my self, so little while later I have a design and built a working application. Demo video after the break.


Ok, hokey title. Jonathan wrote up a really great retrospective on 2011 for JavaFX, and it inspired me to want to write a post detailing the plans and goals I have for JavaFX in the new year (and I’m sure Jonathan and Jasper would concur).

Without further ado, my top 10 list of goals for 2012!


I just sent the following letter to the OpenJDK community “discuss” mailing list:

Hi OpenJDK community!

As announced at JavaOne we (Oracle) would love to contribute JavaFX into OpenJDK as a new project called “JFX”. For some who have been following along, we’ve talked about this for a long time but finally (finally!) we’re ready to act on it and open source the platform. We are not just interested in open sourcing the code, however, we also want to move into an open development model. We already have an open bug database[1]. The project uses Mercurial, so we should fit in pretty well into OpenJDK.

Our basic motivation for wanting to open source JFX is to built a community and ecosystem support and adoption around JavaFX by increasing transparency. Of course we are also interested in getting patches and early feedback from the community[2]! Our goal is to provide the next-generation Java client toolkit, and JFX would be the next step along that path, which hopefully culminates in a JSR for the Java 9 timeframe and including JFX as proper part of the JDK. I would be the initial Project lead for JFX.

A little bit about our project:
It is a significant contribution to the corpus of open source code
It includes over 6000+ public API members (methods / constructors / etc)
It includes over 11,500 unit tests
Core libraries such as observable collections and binding
Scene graph, effects, graphics
CSS support for JavaFX
Prism (hardware accelerated graphics, including openGL and D3D and java2D implementations)
Glass (windowing system, base porting layer, including mac, linux, and windows implementations)
UI Controls and Charts

Our builds are all Ant, with JUnit for testing (there is some ‘make’ in there for native parts). We also have NetBeans projects setup for each area. There is a lot of code that we’ll be releasing, so as a matter of practicality we’re going to release different parts of JavaFX over the course of the next few months, starting with UI controls followed by charts. We’ll put up a full roadmap onto our project pages, should we be approved to become part of OpenJDK. We’ll make sure that the open source code is always fully buildable by anybody using the sources + a binary plug (which will become unnecessary as we open source the remaining pieces). All of the above listed modules will be open sourced and fully buildable.

What do you think? I’d love to hear any issues and hopefully be able to resolve those prior to requesting an official vote.


[2] A good example of the sort of interesting stuff going on out there can be found here:

This is the first step towards open sourcing JavaFX into OpenJDK. First I wanted to talk with the community about it, and if it looks favorable, I’ll follow up with an official project proposal. Here’s hoping! If you are a subscriber to “discuss”, please go and throw in some good word for the idea and if you have any questions I’d like to hear those too. If you aren’t a member of “discuss”, go join :-). You can do so here.

It feels good to finally be getting this all out in the open source!

There has been a very interesting thread in the JavaFX OTN forums about FXML and dependency injection. I went and downloaded Google Guice and wrote a small sample to try it all out. Things are not perfect quite yet (I still need full Unified Expression Language support added to FXML), but so very, very, very close!

What I ultimately hope to accomplish with FXML and CSS in JavaFX enterprise applications is that we (a) fully separate the visuals from the “controller”, (b) are left with a very simple “controller” that is highly testable, and (c) everything is highly modular.

CSS allows the designer to come in after the fact and modify the look of a UI without the developer’s help, and without a full build cycle. FXML allows a developer or designer to alter the structure of the view without a full build cycle. So (a) should be well in hand, especially if the controller itself can be injected rather than declared directly in the FXML file as it is today. (I’m OK with, even prefer, saying “I would like to have a FooController for this FXML file, if you please”, but what would really rock is if the FooController were an interface or abstract class rather than always being a concrete class, such that a DI framework like Guice could find the appropriate implementation and supply it).

This past Monday in technical keynote at JavaOne 2011 we made a series of announcements, which I referred to in the recent posting. The video for the keynote can be seen (along with a lot of other videos) on the Oracle Media Network pages.


I was just working my way through the last few days of posts on the JavaFX OTN forums and noticed somebody who was trying to learn how to write a custom layout pane and included the following code in the forum posting:

public class MyLayout extends Pane {
@Override protected void layoutChildren() {

@Override protected void layoutInArea(Node arg0, double arg1, double arg2,
double arg3, double arg4, double arg5,
HPos arg6, VPos arg7) {

@Override protected void impl_layoutBoundsChanged() {

This reminded me that I had failed to write a blog warning of the perils of using impl_ methods in JavaFX 2.0. DON’T EVER USE THEM!!