FX Experience Has Gone Read-Only

I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!

tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.

This time around I have an interview with Tom Schindl, a developer who has been active on the openjfx-dev mailing list teaching the Oracle engineers a thing or two about OSGi, and how to play nice with it. We really value his feedback, and all other feedback we receive from members of the JavaFX community. Enjoy the interview, and if you have any feedback about what Tom is discussing, please feel free to leave comments on this post. I’ll make sure he keeps an eye out and answers any questions you may have :-).

Hi Tom – could you please introduce yourself to everyone?
In my daytime job I’m cofounder and CTO of a small software company named BestSolution.at located in western Austria where we develop solutions for and provide consulting to customers around the world.

We have put our focus in the last years on OSGi and Eclipse technologies and because of this engagement I’ve become a committer on various Eclipse projects including the next generation of the Eclipse Platform named e4 (the foundation of the Eclipse 4.2 SDK) for which I wrote the initial prototype together with an employee from IBM.

You’re a relative newcomer to the JavaFX world, joining around the release of JavaFX 2.0. What drew you into JavaFX?
At the time JavaFX 2.0 got released I was searching since some time already for an alternate UI technology. Because of Eclipse RCP we historically worked and still work in many project with SWT. Like any technology SWT has its advantages and disadvantages. One of major problems is and was that you can’t really style all properties of a control because the widget is not drawn by SWT but the native widgettoolkit and so I was searching for another UI technology which doesn’t have such a limitation.

So JavaFX 2.0 came just at the right time for me and I liked the design of the toolkit including its property and observables API (at Eclipse I’ve been involved in the eclipse databinding library so I know this problem domain a bit) and most importantly the useage of CSS to declaratively styling the UI, interesting enough is that once more at Eclipse we decided to use CSS as well to style the e4 platform.

You’ve been working really hard on a project – would you like to explain what it is?
I’ve been working since last year on a set of Eclipse Plug-ins who should make the development experience of JavaFX applications in Eclipse as good or better than the one you get when writing SWT and Swing apps. The project is named e(fx)clipse and can be used in Eclipse 3.7.2 and later. To make the development experience as good as possible we provide all in one downloads so that people can start developing JavaFX applications immediately.

So what special tooling does e(fx)clipse provide:

  1. Specialized CSS-Editor which knows the css-extensions of JavaFX
    While exploring JavaFX I found it quite tedious that I had to have the CSS-Documentation open while developing which contradicts a bit the idea of an IDE – so the development experience was very bad. At the same time I checked out JavaFX I was also experimenting with the Xtext framework which allows you to define your custom DSL and generate Eclipse tooling for it. CSS is nothing more than a DSL to style applications so instead of making up an artificial example DSL to learn about this new framework I decided to implement something useful
  2. Specialized XML-Editor for FXML
    FXML is a serialisation specification for a Java-Object graph so unlike other XML formats it can’t have a fixed DTD/Schema which makes default XML-Editors useless to edit FXML-Files in your IDE.Like most projects at Eclipse the XML-Editor shipped by the WTP-Project allows to plug yourself in and provide content-proposals, hover-information. Since the last release (0.0.14) we provide such an extension. It consults the your projects classpath and provides intelligent autocompletion for JavaFX-Objects (e.g. properties) and Hover-Popups showing the JavaDoc of the JavaFX-Class
  3. fxgraph-DSL as a replacement for FXML
    I’m not a big fan of directly editing XML-Files so I developed a small DSL using Xtext and XBase which removes the noise, in the background the DSL is translated into FXML which means there’s no runtime library needed. It also allows to switch to another IDE like e.g. Netbeans or SceneBuilder and continue developing with those tools.The last missing piece to make this a full cycle is a way to translate FXML-Files in the fxgraph which is scheduled for one of the next releases.
  4. Live preview while editing
    One of the advantage of WYSIWYG-Editors like Scene Builder is that you have an immediate idea how your UI looks like. I’m still not 100% sold on those visual designers because I think one is a lot faster with the keyboard than one is with the mouse if you are a skilled developer (not talking about designers here).To close the gap I’ve developed a live preview of your FXML and fxgraph files who provide you immediate feedback on your resulting UI while you are editing. Especially fxgraph has extra syntax to e.g. fill your controls with content to give you better idea of how the UI will look like in the end.

Beside providing tooling for Eclipse e(fx)clipse also provides runtime components you can use in your own JavaFX applications. The most important one is probably an Equinox-Extension that makes JavaFX run without problems in the Equinox-OSGi-Container. Combining this OSGi support with JavaFX’ SWT integration allows developers to develop Eclipse plug-ins who make use of JavaFX inside their View/EditorPart.

For the Eclipse 3.x platform using the FXCanvas-Bridge is the only possibility to make use of JavaFX in your RCP applications. For the new Eclipse 4 Application Platform (EAP) the story is a bit different and better. The EAP is built around modern software paradigms like a central application model, dependency injection, a publish and subscribe event system and a pure service architecture. In this concept rendering a UI is nothing more than a special services the platform requests from a provider.

By the default the platform shipped by Eclipse provides a rendering service which uses SWT – e(fx)clipse provides an alternate rendering service which uses JavaFX. The current implementation is in alpha state. I’m currently searching for companies who would fund my work on in this area so that we can ship a enterprise ready rendering service in the not too future distance.

To the right is a screenshot of an application developed on top of the Eclipse 4 Application Platform which uses only JavaFX for rendering.

I’ve recently shown the power of JavaFX and my runtime components by combining them with Eclipse technlogies like JDT and Orion to write a mini Java-IDE with a extremly small effort (2 days of work).

I’m going to assume you use Eclipse as your IDE. How do find working with JavaFX in Eclipse?
Though writing JavaFX applications without the help of an extra plugin is possible the development experience is not as good it is with other technologies. It starts already with setting up your classpath. Most people make the mistake that they add it directly to their projects classpath instead of defining a Library and hence their project can’t be shared easily.

As outlined above the next problem is CSS – the default editors have no clue about the “-fx” css properties and you have to have a browser open with the CSS-Documentation. The same applies to FXML. To summerize you can develop JavaFX applications without any extra plugin but your experience will not be satisfying.

Naturally I’m a bit biased because the only JavaFX tooling for Eclipse I know of is developed by myself but I think if you install my extensions developing JavaFX applications is a very smooth experience.

I know you’re a very strong proponent of OSGi. How does JavaFX rate in this regard, and what would you like to see changed in future releases?
Frankly this was the only disappointing thing when I came to JavaFX. It was not designed with OSGi in mind. Since the early days many of the problems have been addressed (e.g. FXML loading now supports a custom classloader, …).

My Equinox-OSGi-Integration is quite stable now and so the experience people in the Eclipse Ecosystem who normally use Equinox is a good one. One thing I’d like to see done in JavaFX is that it gets split into smaller chunks but I think this will happen anyways because of JDK8 and jigsaw. I’d very much welcome it if JavaFX would run out of the box in OSGi-Containers but for the time being I’m happy with my solution which also has advantages because it allows different deployment strategies.

Do you use JavaFX commercially, or is it more of a hobby for you?
No not yet. Most of our business is still centered around Eclipse RCP and Webdevelopment – the first thing we’ll probably integrate are charts using FXCanvas but because we our main target platforms are Windows and Linux this has to wait until JavaFX for Linux is GA.

What do you think of JavaFX 2 now that it is Java-based?
I really like JavaFX. It is the first time I have the feeling Java on the desktop has a future. All we need now is an application framework to write medium to big commercial applications. As stated above this framework already exists (Eclipse 4 Application Platform) and I’ve shown in prototypes that there’s no technical reason to make it enterprise ready.

Do you program JavaFX using Java, FXML, or are you a fan of the various DSLs (most notably GroovyFX and ScalaFX)?
I’ve never worked with Groovy and Scala so those 2 DSLs are not as appealing to me as they are to other developers. I’m naturally using and advertising fxgraph as a DSL to author JavaFX UIs instead of directly writing FXML.

When we talk about alternate programming languages to write JavaFX applications I’m an Xtend fan and have blogged already about my experiments with it. I can only advise Eclipse IDE users to take a look at it. Their tooling is extremly good, you have modern language features like closures, multiline strings, dynamic dispatching, a powerful switch and many more but because Xtend is not compiled to byte code directly but translated in ordinary Java code it can be used for example also with GWT and for me more importantly it is not a mystery of what the compiler produces because I can still look and debug through the code (you can choose between debugging through Xtend code or the Java code)

Prior to developing with JavaFX, did you use Swing? What are your thoughts on JavaFX compared to Swing in terms of performance, functionality/features, and ease of development?
My Swing experience is very very small. I’ve been using SWT for the last 8 years. Compared to SWT I like how easy I can style my UI with CSS including stuff like paddings and margins which is something e.g. SWT is unable to do.

One thing I really miss in JavaFX is a TreeTable control and I can only hope Oracle is not making the same mistake they made with Swing where such a control is still not part of the default toolkit.

What are some of the ‘gotchas’ that trip you up in JavaFX? What would you have done differently?
Did I say that it sometimes drive me mad that you didn’t designed it with OSGi in mind 🙂

What really drives me nuts recently is the decision that no SDK zips are shipped for the final release. Oracle says that this is because JavaFX will ship with the JDK in the future, and whilst this is a good idea, the problem I see with this is that the shipping within the JDK is not a full replacement for shipping the JavaFX SDK as a zip.

I’ll give you two examples:

  • The JDK does not ship with JavaDoc because typically all public APIs are delivered as source files with their JavaDoc included. Many parts of JavaFX are not yet opensourced so their source can’t be shipped, and those parts opensourced are not shipped either. Developers without internet access now (e.g. when you our traveling, …) have a very bad development experience because their IDE can’t help them the way they are used to
  • The JDK is not shipped as an extractable file on all systems (read windows and mac) cross platform packaging (e.g. for OSGi) is completely broken.

Beside this the development experience is quite good.

What are you really wanting to see in future releases of JavaFX?
I’d like to see support for iOS and Android. We are currently using HTML5 on those devices to do crossplatform development but I’d really like to leverage Java and JavaFX on those devices.

3D support is not that important for me so I’d like to see putting as many resources on iOS/Android support and improvements of the current controls and implementing new ones.

Thanks for taking the time to chat with me. Do you have anything else you’d like to say to the readers?
I hope people like my tooling and if they haven’t yet tried it they should give it a try. We are open for ideas, feedback and criticism. I think that e(fx)clipse is on par with the support you find in Netbeans. Our runtime components have a lot of potential in the future we currently search for companies who are in need of an application platform and fund the bootstraping of it.