JavaFX is a completely new UI toolkit for the Java platform. In the former days 1.3 you had to use an extra language called FXScript I guess was the name, so you had to learn a new language and they with JavaFX 2, you have now Java API, can use any VM language to target and write your UIs in this shiny new toolkit, and the really cool thing about the toolkit it’s not only a UI toolkit which has widgets but it’s also a multimedia platform so you can embed videos, audio and all that stuff in your application. You work on accelerated hardware, you work with DirectX and with OpenGL, so you get real the best performance from the graphics engine which frees you CPU from doing all the rendering stuff for you, which is a quite cool thing, and it really has support for styling your UI using CSS which is very important when there are designers on your team who have a different idea of how the UI looks like.
Alex: So instead of doing all of the rendering on the CPU like it’s done within Swing, you have this declarative specification that essentially gets rendered by the graphics engine.
Right, you create a scene graph model of the UI and then JavaFX takes care to translate that to shader programs for effects and all the stuff.
2. How long has JavaFX being with us in the JVMs?
I guess, I’m not sure of the dates exactly but I think it started with Java 7, when we got JavaFX, but there it was an extra library, you had to extra download it and install it on your system. With some of the update releases of Java 7, they added and bundled it with the JRE and the JDK, but it was not on the class path, so you had to create your own class path to get JavaFX loaded. It was only bundled and when they went to Java 8, we now have JavaFX which is part of the extension class path and so you can use it for your applications by default, unless you are using Equinox which does strip off the extension class path, and is not loading libraries through there, so that’s one thing the e(fx)clipse project is providing to you if you use OSGi plus Equinox we make sure the JavaFX libraries can get loaded without any hassles.
Typically JavaFX applications have three parts: there is Java for your logic and creation, then to define the UI you have a declarative language called FXML which is a simple XML file and you need to have CSS, so by default from Eclipse you get a Java editor, which is one of the best in the world, but you don’t get support for FXML to code that, so we have an FXML editor which has the same features that you are used to from your Java editor, autocomplete and all the stuff in there, and we have a very, very good CSS editor which knows all the properties that you have in JavaFX and really applies them to the editor and gives you a lot of hints when you are doing JavaFX editing, that’s the tooling. Of course you have some wizards to bootstrap applications and all the stuff, so that’s the main part of the tooling.
4. And then you talked about the runtime, how does JavaFX fit in with the E4 way of rendering UIs?
The good thing about Eclipse 4 is when we designed it and I was part of the initial design team, then we really split off the core part of the application model and rendering UI is only a simple service in the whole system. So with JavaFX and e(fx)clipse we’ve been able to leverage all the Eclipse 4 stuff, stripping of as a routine replacing the UI layer for JavaFX and can create astonishing and really up to date applications for the desktop on Java.
5. What kind of graphical effects can you have for those E4 applications when they are built on JavaFX?
You can do transitions when you switch perspectives; you can do fade over effect; let things fly in and fly out; you can add 3D models inside your scene graph — all those things come for free with JavaFX; embed a video; embed a browser with a web view to browse some web page — they use WebKit as underlying rendering engine — all this is available to you by default, using Eclipse 4 + JavaFX something that you have to do manually, for example embedding a video in SWT applications — that’s a nightmare because it’s not that easy to get that in. So this is what you get for free from JavaFX, and you can make your applications really looking slick, really comparable to applications that you write with HTML today, that’s the main advantage.
We have tutorials at the Wiki, our webpage is www.efxclipse.org, there we link up to an all-in-one download where you get an Eclipse IDE with the tooling preinstalled, so you don’t have to take care of installing the tooling on top of an Eclipse IDE that you already have, so download this, extract it, start Eclipse and you can start developing JavaFX applications.
As an option, e(fx)clipse provides them by default, so I think many people are now looking — if you make decision you are not going to the web, you are staying on the desktop, I think JavaFX is going to be a natural choice in future because SWT is going nowhere, it’s done in the end, at least that’s my impression of it. So if you go to the desktop in the next few years you probably should consider using JavaFX, and so we are seeing a rise in customers coming to us asking for consulting support and support for priority bug fixing and all the stuff, so things are getting really, really well now with JavaFX.
Not really because we consume the core platform which is 90% of Eclipse, what the Eclipse platform provides and only add those extra 10% as part of our FX project, which is an Eclipse project so you get all the IP stuff, everything is IP clean so you have the same standards that you have with API contracts and all the stuff, so we really follow the Eclipse process. So I don’t think that we would put that back to the platform because as the main platform for the IDE is SWT, that’s something that won’t change because so much UI has been written on top of this SWT layer — that IDE will always stay at the level of SWT and so it doesn’t make sense to go back with the renderers to the platform, to keep them in the e(fx)clipse project.
At least that’s our idea, I think we have one of the major or best platforms, it’s industrial proven, it renders the Eclipse IDE so it’s used every day from thousands and hundred thousands of developers, so the core is very stable and we only add another 10% to do the JavaFX rendering and we are at the same level from the feature level that you get from SWT port. So it's a very clean codebase, very small, I’d say it’s about 5000 lines of code which does the rendering that’s it, the rest is part of the Eclipse core platform.
Alex: Sounds like it’s going to be a great future for JavaFX on the Eclipse platform.
I think so, yes, as I said, many people are now looking at it and when they start a new RCP application, many people now come to us and say: “Ok, we want to go JavaFX instead of SWT”.
Alex: Tom Schindl, thank you very much!
Thanks!