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!

Number 10: Bug Fixes

Ah, bug fixes! This is an area that we could really use your help with! We’re getting the bug reports, which is good, but I’d love to see some folks step up and contribute patches as well. We’ve devoted the majority of 2.0.2 and 2.1 and 2.2 for bug fixing (although there is plenty of feature work going on there as well, most of it is supposed to be about fixing bugs). The situation we want to avoid is one where we have an ever increasing bug count. I want to see the actual total number of bugs go down, before we start adding significant amounts of new features. This is a difficult thing to do — as adoption increases, so does the pressure to add features that real developers need to complete real projects. But without discipline, we’ll spend all our time on new features! Focusing on bug fixes now will reduce our technical debt. Getting out of debt is a classic new year’s goal, right?!

Number 9: More (Regular) Blog Posts

Like losing weight (which is also one of this year’s resolutions, ahem) this is a perennial favorite. There’s always so much interesting stuff to talk about, and it seems, so little time to do it in. It is easier now that we’re open source — we can talk about things as they come up instead of having to “buffer them up” until the next release. So three cheers for open source!

Number 8: Infrastructure Improvements

I have a long list of things I’d like to see improved in the OpenJFX project to make it easier for people to participate and contribute. These would not just be improvements “for open source folks” but really for all of us (since we are going to be using the exact same tools as we move to developing completely in OpenJFX). For example, I want to get the full set of Atlassian tools in place, so that we have code reviews via Cruicible, bugs via JIRA, Green Hopper for agile planning, Confluence for WIKI, and so forth. I also want to get FindBugs completely integrated with the build system, externalize the hudson server for building OpenJFX binaries and doing the test runs, releasing the SQE functional tests and testing framework, and more.

Number 7: Performance

Performance is always one of those things I’m interested in seeing improvements on. JavaFX is in decent shape, but there is a lot of room for improvement. From the lowest levels of graphics performance to the highest levels of UI controls and the scene graph, there is plenty of work to be done. Most of the really obvious stuff has already been done, but there is a lot more we could do. We have a really great performance team that keeps tabs on everything, getting the tools we use released so that everybody working on OpenJFX can use them would be awesome.

Number 6: Documentation

I have a personal goal to provide reams of documentation on the OpenJFX WIKI, as soon as we have one! We do have some great documentation produced by our professional writers, and we have fairly good API coverage. But there are two areas that I think need improvement. First, the OpenJFX project needs a large and robust set of developer documentation detailing the architecture and design decisions, naming conventions, and so on used in the project. There is a lot of institutional knowledge and experience trapped in our heads that needs to be put down so that anybody coming to OpenJFX knows the back story and rationale and can understand the code and, most importantly, contribute to the project in a way that is consistent with the design center for JavaFX.

Secondly, we need to improve the quality of much of our API documentation (javadoc). Some areas are very well covered, but others are not. I’d like to see very rich example sections for every class indicating not only what the class is, but how it is intended to be used. I also like these sorts of examples in the documentation because if you have to cheat and cut corners to make the documentation examples clear (using pseudo code) then that is often a very good indicator that you don’t have an API that is really all that easy to use. So writing all that sample code is pretty instructive both for the reader and for the author.

Also, I want to see much more in depth documentation on the package level. The controls package should have documentation describing how to use controls in an MVC application, for example, using FXML and so forth and how to bind the controls to various data models.

Number 5: Embedded

As announced at JavaOne 2011, the new embedded platforms coming from Oracle (CDC) will be using JavaFX as the UI technology. That is slated for final release in 2013 along with Java 8 and JavaFX 3. However, there is a lot of work that has to be done this year to make this a reality, including adding touch event support to the platform. Having working embedded prototypes for this year is high on the list of goals for JavaFX!

Number 4: Linux

You’ve been heard. Linux was always on the roadmap, but delivering the final GA product this year, and beta binaries very soon is my goal. Oracle has already committed to releasing the Linux version this year, so that’s good to go. The holdup on getting the 2.1 weekly builds of Linux released is just some quality sanity checks by the team (they’d rather have something halfway usable than DOA when the first weekly builds go out). I suspect they’re farther along than they’re letting on, they’re a bright group of engineers 🙂

Number 3: Mac

I’ve been on a Mac for going on 5 years now, I think. JavaFX and Java on Mac is making great progress. With Linux (GTK) and Mac support, added to the existing Windows support, we’ll finally be able to truly claim cross platform desktop development. With the upcoming embedded support, we’ll be able to also claim cross platform on embedded devices.

Number 2: Scene Builder

The absolute #1 pain point I have when writing JavaFX applications right now is laying out my windows. It isn’t so much the API — I hate doing manual layout in code, regardless of the API. I have always been of the opinion that you use the right tool for the job — you use Photoshop or Illustrator for designing graphics, you use Maya for 3D animations, you use code for writing logic, and you use a layout tool such as Scene Builder to visually construct your application.

Initially we’re focusing Scene Builder on the task of layout. After we’ve absolutely nailed that, we’ll move on to data binding and other such functionality. At the same time, we’re working to add more application framework API to JavaFX, and will build Scene Builder around these APIs, so that you can use a visual tool with no compromises — solid MVC app support using visual construction and code for business logic.

There will be a public beta, and there will be a GA for Scene Builder this year. And it will be free.

Number 1: Open Source

Finally, my #1 goal for this year is to fully and completely open source JavaFX. Much like the JDK, we will likely have some proprietary bits that are used the final JavaFX binaries that we ship (such as Ductus for shape rasterization instead of Open Pisces), but I want to eliminate even that.

We have at times used language like “the open source community” and “outside contributors” — as if there is a difference between “us” and “them”. I’ve used such language myself! My goal for 2012 is to completely erase this boundary. There will no longer be an “us” and “them”, but just “us”. Those of us working on OpenJFX, whether from Oracle or from anywhere else, will operate as a single team with shared access to information and bugs and code. There will at times need to be some distinction (security bugs for example must, of necessity, be treated differently) but in all material aspects OpenJFX should be a completely open development project.

I hope that was useful and you have a prosperous 2012, and enjoy using JavaFX! And more importantly, that you come and help on OpenJFX!