This interview is with a team mate of mine – David Grieve. As you’ll discover in this interview, he has been involved with JavaFX for a long time. I won’t spoil any more of the interview – so enjoy and feel free to leave comments in this blog related to JavaFX CSS support.

One small note: I will be away at JavaOne Japan for the next two weeks, so it is likely I won’t publish any more of the interviews I have until I get back. Now, on with the interview! 🙂

Hi David. Could you please introduce yourself to everyone?
I’m a graduate of the University of Pittsburgh with a Bachelor degree in Computer Science. I got started in Java in 1997 when I helped develop a Java-based network-management tool. Since then, I’ve been programming almost exclusively in Java. On the personal side, I live in New Hampshire with my wife and our two children.

You’ve been in the JavaFX controls team longer than I have – how long have you been working on JavaFX?
I’ve been working on JavaFX since 2008 when I led the development of the Media Browser tutorial which was part of the 1.0 effort. I became part of the UI controls team around the start of the 1.2 development cycle. I took on the development of CSS at that time, which would have been March, 2009, if I recall correctly. It all seems so long ago.

As long as I’ve known you, you’ve always worked on CSS support in JavaFX. Firstly, I must thank you – CSS in JavaFX is wonderful.
Thanks! But a lot of the credit has to go to Richard and Jasper who set the direction. Concepts that really make JavaFX CSS powerful – such as color derivation, property lookup, and multiple background colors and borders – come from them. I just put the code together to make it all work.

What does a regular day entail for you?
First, I take the dog for a walk, then…

Like everybody else on the team, if I’m not implementing some new feature, my day is driven by bugs in JIRA. Chasing down the root cause can be quite a challenge at times. Most often, the problem is something subtle that ends up being an easy fix. For instance, I once spent a couple of days tracking down a problem that was solved by casting a 1 to a long! The whole debug-fix-test cycle is time consuming given all the variations that CSS allows.

Sometimes, it feels like all I do is debug. Every node in the scenegraph goes through CSS before layout or anything else. If something is wrong in the scenegraph, such as a node has the wrong fill or has the wrong alignment, the bug may be in CSS. So I spend a lot of time proving or disproving whether CSS is at fault. This is great, actually. I’ve been all over the code.

What kind of mindset is necessary to work on CSS – is your focus on following a certain CSS specification to the letter, on performance, on extending functionality, or is it all of the above?
Working with standards is nothing new to me. Early in my career, I worked in OSI conformance testing and prior to joining the controls team, I was working with GSM telephony. I think following the spec is important, but JavaFX doesn’t follow it to the letter. There are some concepts in CSS that don’t translate to the scenegraph. Also, while JavaFX CSS is based on the W3C specs, we’ve added a lot of extensions. For example, the Region layout container is close to the CSS box model, but JavaFX allows for multiple layers. Most of the CSS properties in JavaFX are prefixed with -fx- and will be ignored by other parsers. In the future, I’d really like to see JavaFX use standard properties as much as possible. Wouldn’t it be nice to use the same stylesheet for an HTML page as you would for a JavaFX scene?

Performance is always a concern. Any time I make a change or fix a bug, my biggest concern is regressions, both performance and functionality. In 2.1, I’ve added a lot of new junit tests. They only scratch the surface, but they’ve helped with avoiding regressions. There is also a team that does performance analysis [editors note: I will be interviewing the performance team separately in the coming weeks]. Last fall, the controls team spent an afternoon with some of them going over the tests they run. Now, I can run the same tests and use the same tools to head off any performance regressions.

As for extending functionality, the list of new features continues to grow. But, my immediate focus is on the core functionality. I’d much rather build on a solid foundation.

How difficult is it to get the power of CSS into a UI toolkit at the lowest level?
In 2.1, I introduced classes that extend some of the javafx.beans.property classes so that properties that can be styled through CSS play nicely with the CSS implementation. This was a huge step forward in making the code simpler and more robust. There is still room for improvement, but the model is easy to follow. Currently, however, this is all private implementation. Clearly, we need to make some of the API public at some point in the future.

Performance, from my perspective as a control developer, is perhaps the biggest concern with CSS. How does JavaFX manage to run so fast?!
Toward the end of the 2.0 release, CSS was on the hot-seat for performance. I was able to get some minor gains by using a bit mask to represent psuedo-class state, but it wasn’t enough. It was to the point that we were considering doing away with the lookup feature, which seemed to be the bottleneck. Various approaches for caching calculated values failed to give any noticeable performance gain. On the verge of giving up, an idea struck me of how we might cache values based on a node’s ancestry and pseudo-class state. If you look at Node’s implementation, you’ll find a Reference<StyleCacheKey> which came out of that work.

Now I’m faced with new performance targets so we should see CSS get even faster. I really enjoy these kinds of challenges.

From my recollection, you’ve been through a few different CSS implementations over the years. What drove these redevelopments?
Job security, of course! Really, though, the basic model has been in place since JavaFX 1.3. Some of the changes have come about as a result of taking an expedient to get functionality and then later refinement. Early on, there were some methods that were needed because the property model wasn’t completely worked out. I’ve also taken some wrong turns along the way. So, I’ll write these redevelopments off to using an incremental software development methodology. Yeah. That sounds good.

How complete is the CSS implementation in JavaFX 2.1? Is there anything missing that you would like to see in future releases?
I’ve mentioned some things already, but I’d really like to see support for animations, attribute selectors, and structural pseudo-classes.

I don’t think many people appreciate just how powerful the JavaFX CSS is. Is there one feature you’d like to highlight to people?
Can I mention two? First is the ladder function, which takes a color as an input and selects a stop based on the brightness of the color. This is really useful for picking a foreground color that contrasts nicely with the background. The other is property lookup. Simply put, you can use another property name in place of an actual value in a style. When the value is calculated, the code will lookup the value of the other property. This feature is used extensively in caspian.css. Readers can find out more about these and other JavaFX CSS features by following the link to the “CSS Reference Guide” from http://docs.oracle.com/javafx.

Thanks so much for taking the time to answer these questions. Do you have anything else you’d like to mention to the readers?
I just want to say thanks for all the feedback I’ve received – in the form of bugs and constructive criticism – from the community. The input is invaluable.