Today I have an interview with Daniel Zwolenski, a developer who has been involved with JavaFX, both from a commercial point of view, and as part of the open source community. He is active in openjfx-dev mailing list discussions, as well as running a very popular blog on using JavaFX in enterprise environments. I first had the privilege to meet up with Daniel when I was living in Brisbane, Australia last year, and he continues to be a contributor to the future of OpenJFX discussions today. Without further ado, lets get go with the interview – please enjoy! 🙂

Hi Daniel – could you please introduce yourself to everyone?
For the last 14 years I have been working in the Java application space, designing and building Java applications of all shapes and sizes for many different clients and industries. I’m based in Australia, currently in Melbourne, but I have worked in the UK, Ireland and very briefly in France.

Among many other projects, I was the architect and led the development of Coinland (an online virtual world for kids sponsored by one of the major Australian banks), I’ve driven the re-development of SMART (the key reporting tool for the National Assessment Program for Literacy and Numeracy in the state of NSW), and I’ve been a core part of the team that developed the management system for Tourism Australia’s ATE (the largest tourism expo in the southern hemisphere).

I’ve deliberately stayed as an independent contractor, changing fields and companies in search of the most interesting and challenging work. I love the variety, and opportunity this provides to grow my skills and expand my experiences. I have managed teams of all shapes and sizes, worked in with large corporate teams, and at times, acted as a one-man development team.

I get a buzz from interacting with my users and user interface development has always been my preferred space. I cut my teeth on Microsoft’s Visual C++ and MFC platform, and then happily made the move to Java when Swing was released. I’ve worked in the web space, but always felt limited by what I could provide for my users, even when using technologies like GWT. I’ve also developed Android applications and been involved with some iPhone development.

JavaFX is a very natural fit for me, and a platform that I really want to see dominate mainstream application development. I want to be at the point where 9 out of 10 contracts on seek.com are looking for JavaFX developers, and when I walk in and pick up some legacy system, it’s a JavaFX application, not a webapp. In a perfect world I would never have to debug another cross-browser JavaScript problem, or worry about what will happen to my session scope if the user hits the back-button.

Although I love to code, I don’t use computers much outside of development. I spend a lot of my time working with non-profit organisations, especially environmental ones. Recently I have taken on a contract with Our Community, a group providing software and services to the non-profit sector. It’s an awesome place that is the perfect balance of commercial systems development, community awareness and social conscious. Unfortunately they are not yet using JavaFX, but I hope to have them converted before too long!

You’re a relative newcomer to the JavaFX world, joining around the release of JavaFX 2.0. What drew you into JavaFX?
I’ve been developing Swing applications for the bulk of my career. I love the control you have with Swing, the way you can totally customise the user experience and create something really engaging, and that you can do all this using regular, clean, type-safe Java.

I would hunt out contracts that were using Swing, especially those focusing on data visualisation with custom graphics, animations and diagrams. I’d even take pay cuts to work on these rather than be forced to build yet another HTML/CSS web form application (this was in the days before jQuery, HTML5 and Twitter Bootstrap – web development is still painful but at least now you can actually build a rich user experience in it).

The big problem with Swing however is that out of the box, it is so very, very ugly. Sure you can customise it to look however you want (and I always did) but that takes a lot of effort. I spent a lot of my time building custom controls that made Swing prettier, giving it a look and feel more like those we were seeing advance in the web space. I even built my own CSS-like styling system.

It was when I was building my own animation library for Swing components that I really hit problems with Swing’s rendering pipeline (don’t ever try to animate a JPanel containing lots of components!).

I started casting about for something else and discovered JavaFX 2.0. It had everything in it that I’d been trying to force Swing to do against its will for years, and it had much more: animations, styling, a sleek default look and feel that wasn’t obsessed with the flawed ideal of “platform fidelity”, visual effects, multimedia support, and even the promise of 3D and maybe one day mobile platform support. It had me at “hello”.

Did you ever consider using JavaFX when it was pre-2.0 (that is, when it was not Java based, and instead based around the JavaFX Script language)?
Actually I was quite excited about JavaFX 1.0 when it was originally announced. I thought Java was finally going to make it big in the “rich client” space. Swing, the old, reliable but ugly workhorse, was becoming an unloved, obscure, niche technology and more and more I was being forced to build web applications for my clients.

When I looked at JavaFX 1.0 however, I discovered how everything was based around JavaFX Script and was totally deflated. I felt like the JavaFX guys had missed the point. The main reason I hadn’t switched to Flash, or JavaScript, or any of the other major “rich client” alternatives to Swing was simple: they weren’t Java. This JavaFX Script language was just another non-Java addition to the scene and one I totally wasn’t interested in.

When JavaFX 2.0 was announced I was not at all interested in it. It was only when I started looking for something that could do iPad-like animations in Java, that I discovered that JavaFX Script had been dropped in 2.0. Then I started to get excited again and started playing around with it. I’ve not been disappointed either, JavaFX is a true, pure-Java, rich-client library at last! It is as much Swing 2.0 as it is JavaFX 2.0, which is exactly what I’d been waiting for.

You’re very vocal (in a good way!) in the openjfx-dev mailing list. How do you find interacting with other developers on this list, and what do you think of the community forming around OpenJFX?
Ha! I’m sure I talk too much sometimes but I figure the guys on the JavaFX team need to know what we’re doing with the technology and what problems were facing in order to keep things improving. Better to throw too much your way than have you guys fly blind.

One example that highlighted this need to me was when I discovered that practically no one on the JavaFX team had Maven experience. I realised this was probably because Maven is a tool well suited to building business apps and working with a technology stack, but when you develop a framework like JavaFX you are deliberately not using a stack of technologies this way. This really highlighted to me how the JavaFX team might not be exposed to the problems we face on the front line of app development and that our feedback would be really critical for making the platform work for us (we’re still working on clean Maven support, but we’re getting there!).

There are several other vocal members in this community too. When I started out learning JavaFX, the forum was my lifeline and the guys on there helped me get through a lot of early teething problems. As I got more experience I spent a fair bit of time helping others there too, but now ‘jsmith’, ‘shakir.gusaroff’ and several others have totally taken that over and are doing an awe inspiring job – meaning I can spend more time on the developer mailing list.

I totally love that the official JavaFX developers get fully involved in both the forum and the mailing list too. It’s not often you can get that kind of direct communication going with the team actually building the features. That was one of the other things that really attracted me to the JavaFX platform. Sure there were things that were still a bit raw and needed improvement, but the team was open to suggestions and constantly working with the community to make things better.

A while back you were writing a very useful series of articles on your blog, and on the Oracle Technical Network website. What drove you to write these articles, and are they still worthwhile reading for developers?
There’s a lot of very good ‘getting started’ documentation on the JavaFX documentation site, but people are soon looking for ways to go beyond this. They want to know how to save things to a database, how to make their JavaFX client talk to a server over the web, and how to make sure this is all secure. All the things that I’ve had to work out in order to use JavaFX in my applications.

There was no way the JavaFX doco could cover all of this, because in the grander scheme of things, JavaFX is really only one piece of a bigger puzzle. That’s why I started a blog on this.

Although these articles use 2.0 code, they are most definitely still worth reading now. Anyone who is building a real, professional, business application (especially a client-server, database one) will probably get something out of these. Not everyone will agree with the approach and architecture I suggest, but I think even if people don’t like the way I do it, they will get ideas that they can feed into their own architecture.

I have had a few comments about the layout of the site. I tend to write a lot of explanatory information on each topic (or as you put it Jonathan, I’m “very vocal”), and the blog structure doesn’t work so well for this. I’m working on rearranging these posts into pages with a more logical structure and a table of contents. This will take a while however, so in the meantime, I’d suggest going to the first post in the series and stepping through it like a tutorial as opposed to a blog: http://www.zenjava.com/2011/10/23/javafx-2-0-fxml-and-spring/

(Note from Jonathan:You can see more of Daniel’s posts at zenjava.com, and also on the Oracle Technical Network, such as here).

You’ve worked on a few JavaFX-related projects in the past year, both personally and for previous employers. Did you want to outline some of these projects, and what you think JavaFX offers that made you choose JavaFX?
I have worked on two professional projects that use JavaFX, both for Downstream, a company that is developing safety and audit software for the heavy industries sector. These guys are extremely focused on usability as their systems need to be accessible to low-tech, non-english speaking users on mining and engineering sites.

Everything is as graphical as it can be, with animated images of things like padlocks locking on to permit boards, instead of the more traditional text/table based way of showing things. We have touch screens, and tablets all needing iPad-like user interactions with animations and touch-oriented user interfaces. Traditionally, your standard desktop UI library won’t supply this sort of thing out of the box.

I originally built the prototype for these systems in Swing and made everything from scratch using custom drawing routines. As I mentioned earlier, this had me building a suite of stylable, custom widgets, animation libraries and much more. JavaFX came along and offered all of these things for free allowing me to throw away massive chunks of code and end up with better results. Although JavaFX was new, the fact that it was so well supported by Oracle convinced me it was strong enough to use on a commercial application.

The larger application is still under negotiation with clients and I can’t say too much about that, but the smaller application, which allows safety auditors to carry out site inspections using a Windows tablet is currently in final stages of trial and is soon to move into production usage on sites both here in Australia and in nearby countries.

As well as these applications, I have also developed the JFX Flow framework. This is an application framework for building ‘web style’ applications in JFX (i.e. applications that look more like web browser apps with a back/forward style of navigation) and it combines a few things like Spring integration, FXML with an (almost) MVP pattern and a few other little bits and pieces like blocking the screen while loading and animated page transitions.

JFX Flow was born out of necessity – I needed it for my Downstream projects. I figured I may as well open source the framework code for others to use and the Downstream guys were very supportive of this. JFX Flow will work if you want to use it but there are a few things I wish I had done differently and there have also been a couple of releases of JFX since I wrote Flow. One day I’d like to fix it all up and tidy up some loose ends, but that is not likely to happen until I have another client wanting to do something similar.

Having said that, Flow is still a great example of techniques and patterns that people can use in their own projects. If anyone is interested in Flow, I would suggest looking into the code and pulling out the bits that you need for your project rather than trying to use the whole project verbatim. I’m also happy to discuss with anyone who’s interested how I would do things different.

Oh, I also open sourced a little video capture demo program a month or so ago. Video capture/playback is one of the top voted JFX JIRA issues at the moment but this addition is not on the immediate JFX road map. I had a requirement for taking photos in one of my projects, so I knocked up a JFX wrapper for LTI-CIVIL (http://lti-civil.org/). My efforts were pretty minimal on this, the real effort has been done by whoever wrote LTI-CIVIL, so if anyone does make use of this, be sure to drop a thank-you into those guys.

I always give interviewees a chance to have a rant, so, what do you wish JavaFX had, and is there anything you would change about JavaFX as it stands today? Put another way, what are some of the ‘gotchas’ that trip you up in JavaFX? What are you really wanting to see in future releases of JavaFX?
JavaFX on mobile. That’s when I think this story will really get interesting. People haven’t got a strong reason to move away from web applications at the moment. Everyone’s gotten used to web development and all its quirks and things like HTML5 and Twitter Bootstrap have started to hide some of the pain. The mobile device space however, is still wide open. I’ve written a commercial Android application, and played with iOS applications. Neither of these are any kind of fun (Objective C makes me want to cry).

If there was a real, cross-device solution for developing mobile applications then this would be a game changer. If you could then make use of all (or most) of the existing Java libraries on all platforms, well that would only sweeten the deal. Finally, throw in the option to have one programming language that extends across your desktop, mobile and server environments and you will have a hard time arguing against using that platform for any project.

As for things I would have loved to have seen done differently, the big one for me is always going to be CSS. There are two parts to the CSS styling engine – the first is how styles are defined and for this, CSS is nice enough (although JSON would probably be even better, especially for things like gradient fills and effects).

The second part however is how styles are selected and applied to a node. The CSS way of doing this is, in my opinion, incredibly fragile and prone to error. The way ‘selectors’ get applied is something of a magical black art and the result is the butterfly effect: change one attribute in one part of your CSS file and the ripple-on effect can produce subtle differences in your whole application. There is no clean modularisation or encapsulation, no real inheritance and results are not always as you’d expect.

Others will likely disagree with me, but I would have loved to have seen a much more explicit ‘selector’ model used. I would have preferred a simple Java model for defining styles so that they could be created and applied directly in code e.g. something like:

LabelStyle myCoolLabelStyle = new LabelStyleBuilder(myBaseLabelStyle)
                                      .font(“Arial”, 12)
                                      .background(new GradientFill(Color.WHITE, Color.RED))
                                      .border(1, Color.BLACK)
myCoolLabelStyle.apply(myLabel);

Instead of “cascading” style selectors, we could have had “inheritance” where styles extend parent styles in the style sheet. Sure we’d lose a little bit of the magic, but we’d also have a much more robust and predictable system.

With a more direct styling mechanism, we’d also be able to apply styles without adding things to a Scene, meaning we could work out dimensions and other ‘display’ attributes without actually attaching the Node to the scene. Currently we have little gotcha’s where you might want to position something off screen (to animate it in) but you don’t know how big the thing is (and so how much to offset it by to get it off the screen) until you actually attach the Node to the scene so it can be styled.

That’s my pet peeve, but unfortunately I think we are past the point of no return on that one. If that’s the worst I have to deal with though, I think I’ll cope.

I know you’ve got concerns specifically about JavaFX versioning, auto-updating, etc – can you elaborate on what you’d like to see improved in this area in the future?
Yes, I do feel like JFX has dropped the ball a bit on the installation front. The lessons learned from the Swing vs Flash vs AJAX ‘rich client’ battles were painfully obvious: it’s all about the user experience. The better user experience will always win out and the first user experience everyone has is getting the thing running.

JavaFX has done an awesome job of improving the user experience within an application (clean styles, slick animations, etc) but the experience of actually getting Java and JavaFX installed on your machine is a horrible, confusing, error prone process with a visual style that was ugly in the 90’s. This might be ok (just) in a controlled corporate environment, where a system administrator is doing these installs but if we want to appeal to the mass consumer market your average end-user wants the “iStore experience”: point, click, go – and do it with style.

Adding to the problems of the installation experience is the current need for forced auto-updating of the JRE and the problems this causes with backwards compatibility. Applets run as a browser plugin and this plugin has to be constantly upgraded to meet security restrictions enforced by the browsers.

This means that we developers have no control over which version of JavaFX a user will run our application with. I might have built my application with JavaFX 2.0 but the user could have 2.2 or even 3.0 installed. Despite the best intentions of the JFX team, it’s impossible for a UI framework like JavaFX to be fully backwards compatible between versions. Even something as trivial as fixing the way a CSS style works could have a ripple effect right through a UI (for example, pushing a button off the screen or behind another control).

All of this stems from the problem of requiring a centrally ‘installed’ Java runtime that is then shared for all applications. The user is the one that has to administer and manage this runtime, but they are the ones with the least idea as to what each application needs and how a JRE upgrade might affect each Java application they have on their system.

The good news is the JavaFX team are aware of this problem and are actively trying to find ways to make this better. Igor, from the deployment team, has added some awesome support to the JFX packaging tools so that we can now create native installers (such as MSI or exe’s on Windows) that co-bundle a JRE into your distribution. Each deployed application, then has its own runtime within it.

This avoids the problem of the centrally installed JRE but has the drawback of increasing the download size. A small demo app with a co-bundled JRE is currently around 30MB compressed at a minimum (on Windows anyway). So we have a better process than before, but it’s still not perfect.

Java 8 is supposed to address this however as we should be able to create stripped down JRE’s that include only the features we want (e.g. we can exclude AWT, Swing, and a whole lot more). This should make our bundle sizes smaller (my vote would be for the target base footprint to be 4MB compressed), resulting in a pretty sweet installation process that I think will eventually see a move away from Applets and Webstart applications. This can’t happen soon enough in my book.

I’ve had a few discussions with you regarding developing a JavaFX-based app update API. How is this going, and is there any way other developers can help?
As I mentioned above, Igor has done some great work on these new native installers, but as yet there is nothing in place for auto-updating. i.e. downloading and upgrading an application when a new release has been published.

Both Applets and Webstart-deployed applications have this already (with varying degrees of success) and for most applications support for this is a requirement. I don’t think we will get a critical mass of people moving towards the native installer approach until we have this feature available (and the smaller bundle sizes I mentioned earlier).

I decided to prototype an auto-update solution based around the work Igor was doing and I managed to get a crude version running on Windows. There are a few different approaches that could be used so I’ve been soliciting the JFX mailing list for input. The archive of the conversation is at http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-July/002912.html

In general the idea is to provide a Java toolkit that developers can use to plug auto-updating into their applications. There’s a pretty standard set of workflows that can get provided out of the box (e.g. a “check for updates” dialog), but the toolkit would also provide a lower-level API so that developers could customise this experience and do things like prompting for new licence keys, or playing a “what’s new” video.

If this is an area of importance to anyone I would encourage them to have a say on the mailing list now while things are still being worked out. This might be input on the features needed, the strategy used or the actual user experience. Even better would be to make contributions to the code, and I am very happy to open up my POC to a larger group of developers.

The idea of the proof of concept was to get input from the community and to give Igor a base to work off (both in terms of features and possible implementations) when he gets round to looking at the official implementation of this in JavaFX. This is probably a fair way off from happening (I’d guess sometime next year).

The crude prototype I’ve put together will actually work as-is in conjunction with Igor’s native installer tools, so if someone really wants this feature and is not able to wait for the official inclusion, they could take this code and work with it. It’s not overly pretty and not overly robust however so it really needs some more effort put into it.

I’d be happy to work with anyone wanting to develop this further. I lack non-Windows development environments and my C++ code is very rusty, so these would be some of the areas it would be great to get some assistance on.

Thanks for taking the time to chat with me. Do you have anything else you’d like to say to the readers?
Thanks for the questions!

I’d just like to say a big thanks to the JavaFX team for making this platform all that it is, and for continuing to improve it. JavaFX has such awesome potential to be the major platform for rich, user-friendly applications that are also robust and well developed. It’s great to see this happening.

I’d also like to say a big thanks to the JavaFX community for being so supportive and constructive. We’ve got so many great people putting in their spare time supporting and growing the platform and the community. It makes developing in JavaFX a really good and rewarding experience.

I’m excited about where all this is heading. Some of the major features targeted for JavaFX 3.0, along with the deployment and installation improvements are definitely things to keep an eye on.