Our JavaFX UI for JVx is available as maven snapshot:

or only JavaFX extensions

and don't forget the snapshot repository:

Our (research) projects with JavaFX are almost finished. We have awesome results and everything is production ready. The only drop of bitterness is the performance of JavaFX on desktops and mobile devices, but this can be improved by Oracle. It's not in our hands.

What do we have?

We have

• a complete JavaFX UI for JVx
• a custom application frame for mobile applications
• Live CSS manipulation of installed apps (needs debug build)
• Complete Project export for JavaFX mobile projects (JavaFXPorts based gradle project),
  integrated in upcoming VisionX 2.3
• Remote Work-screen loading (via VisionX)
• JVx server runs without limitations on mobile devices
• JVx client runs on mobile devices (for network clients)

How does it look like?

I have some screenshots from two applications. The first one is a standalone JVx application. The whole JVx framework runs on the mobile device. The app is a remote control for our eTV project (it's a brand new side project of our research team).

The app was inspired by MS Metro style ... Windows8 style ... Modern ... Universal ... Windows Store ... Windows apps.

The main screen has some buttons to control our eTV and some buttons open a "popup" with additional options:

eTV Dashboard		eTV Window view
eTV Gallery

The second app will be shown as Video, because we want to demonstrate how we use VisionX to create backoffice apps in under 5 minutes! The app itself isn't complex and does "nothing special", but the same mechanism works for complex applications like our Demo ERP system (read our Code once. Run anywhere post).

Our JavaFX mobile project was based on the great work of Gluon and their JavaFXPorts OpenSource project and also on RoboVM.

After one year of JavaFX development, we thought it's time to write about our experience.

We started in Nov. 2014 with our first bigger JavaFX tests. The idea was an UI implementation for JVx. We thought it should be an easy task because JavaFX is a desktop technology. We had another research project in 2012, but the result wasn't as expected. Sometimes it's a good idea to re-start from scratch!

JavaFX wasn't very popular and is still not a Superstar, but we love researching and we thought it might be a good idea to bet on JavaFX. Not only as pure desktop solution and Swing replacement, but also for mobile app development based on JavaFXPorts and for embedded devices, like Raspberry Pi. So we had this big picture in mind.
We thought it would be awesome to create a single JavaFX application, for all platforms and devices. Sure, some other companies tried to solve this problem as well, but we didn't try to do the same. Our idea was simple and based on JVx. We hade this awesome JVx application framework which enabled GUI and technology independent application development. So we tried to solve the GUI problem because all other things like persistence, remote communcation, i18n, ... were already solved by JVx.

We did different GUI implementations for JVx, before we started with JavaFX. Our first one was based on Swing, followed by QTJambi, GWT, GXT, a headless variant and - last but not least - vaadin. We also made some tests with Flex and Pivot, but we didn't create more than some simple PoC. To be clear: GUI technology know-how was not the problem!

We knew that JavaFX didn't have a solution for MDI and especially a DesktopPane was missing, but it wasn't a problem to create custom components/controls. We had some hard months of development because we found out that JavaFX wasn't a mature toolkit like Swing. We had to find many workarounds for very simple problems and had to create more custom components than expected. We solved most problems in our own code, but it wasn't possible to change some basic problems. We tried to get in contact with the developers, via JIRA, but it was hard to explain real-world use-cases to toolkit developers. Our developers at SIB Visions create custom products and projects together with customers for their needs. So we had many UI toolkit requirements from real users. Some issues were accepted but not all. Many bugs were fixed but we had big problems with Feature Requests. So far so good.

We finished our JavaFX UI implementation in April 2015 and it was a big success, because we had a fresh UI technology with lots new features and animations, transitions, web and media views, .... awesome.

We thought that JavaFX will be improved in 2015/2016 and it will be mature enough to use it for our customers.

Wait... what's the problem with JavaFX?

Performance, Memory, limited chances to modify standard controls

The performance is not good, if you have many controls (= nodes). It's different on Windows, Linux, MacOS. It's much better on MacOS than on any other supported OS. If you develop business/backoffice applications, the performance is very important. Sure, if you create simple form based applications, it doesn't really matter.

We use JVx to develop huge backoffice applications and currently, JavaFX should be used with care.

What do we mean with "performance is not good"?

• Large TableViews have scroll delays
• Layouting sometimes need some "extra repaints"
• Scrolling with many controls is not immediate
• Startup time of an application is too long, compared to e.g. Swing applications

The version number of JavaFX 8 is too high for it's maturity.

JavaFX has big potential but we're not sure if it'll survive it's predecessor Swing.

And we're not alone with our opinion: Should Oracle Spring clean JavaFX

But there are also companies with JavaFX applications: JavaFX Real-world apps

There's more

The toolkit issues are one thing. Another big surprise was that Oracle stopped official ARM support in Jan 2015 which didn't mean that JavaFX doesn't run on ARM devices (RaspberryPi, ...), but it's not officially supported and Oracle doesn't fix bugs or implement improvements.
Thanks to Gluon it's still very easy to use JavaFX on ARM devices.

Another step backwards was the migration to Bugzilla. In 2014 (and earlier), JavaFX was a "newcomer" and announced as Swing replacement. The development process at Oracle was very open and you had a "direct connection" to the development team, or something like that. It was very simple to report issues and to get feedback from the developers. It was fantastic to see and feel the progress. This is different nowadays, because the ticketing system moved from JIRA to Bugzilla and it's more or less readonly for standard developers.

One problem with JavaFX is that Oracle doesn't tell us the strategy behind JavaFX. The investment of Oracle in JavaFX was high, but what will be the next step? It's hard to bet on JavaFX without definitive commitment from Oracle.

But we still hope that JavaFX will be the one and only UI toolkit for Java.

JavaFX for Android and iOS

In summer, we moved forward and tried to use JavaFXPorts. It makes it possible to use your JavaFX application as native Android and iOS apps. Our JavaFX UI worked with some smaller changes out-of-the-box. It was awesome to see our JVx on Android or iOS devices! It was a milestone.

But things have changed since summer because JavaFXPorts has a depency on RoboVM. It was an OpenSource project and was a big win for the community. But now it's a commercial tool (read more). This has no impact for us, but means that we can't offer an out-of-the-box OpenSource solution.

JavaFXPorts also works without RoboVM and there are plans for a JVM running on mobile devices, but this won't solve the problem that you need access to device features/APIs. But we'll see what happens in the next few months.

We had some fun in the last few weeks because we tuned our application frame for mobile devices. A mobile application has some specific characteristics and isn't a 1:1 desktop application. A desktop application usually has a menubar and a toolbar. The same app on a mobile device shouldn't use a menubar or toolbar. It should offer a hamburger button which offers a custom menu. Also the style of the controls should be different on mobile devices, e.g. Tabsets.

There are two interesting projects which offer custom mobile controls. The first is a commercial product, from Gluon and the second one is JFoenix and it's OpenSource (LGPL). We took JFoenix because it met our requirements and JVx is OpenSource.

We have some screenshots in older posts:

• Code once. Run anywhere
• Live CSS hacking

Resume

JavaFX has potential to rule the Java UI world, but it needs an official commitment/statement from Oracle. Now it's unclear if JavaFX is the right UI technology for the future.

We hope that JavaFX is the right toolkit, but we aren't sure. Our investment was risky and high, but no risk - no fun. The results are awesome!

Thanks to JVx the UI technology is not important for us, because if JavaFX won't make the race, we still have Swing or vaadin. It's important to be UI technology independent because it saves time and money and is future save.

We have a short video about our LIVE css hacking feature for mobile JavaFX applications on YouTube:

We demonstrate a mobile JavaFX application, running on a Nexus 9 Tablet. It's a pure JavaFX application with our mobile application frame and it was deployed with JavaFXPorts. In the video, we change some styles on our Laptop and the application updates its styles on demand. This is really useful because resolution/screen size can be different. Sometimes the background color looks different than on a Desktop, ... And it's easy to try out new styles without application restarts - same principle as developer tools for Chrome or FireBug for Firefox.

But how did we implement this feature?

It was too easy

Here are the "secrets":

• A simple socket server for the application
• A custom URL handler for loading remote-retrieved styles
• A simple File watcher for the client

That's it!

But to be honest, the custom URL handler was very tricky, because we tried to find a very smart, non-static, solution. And every platform has its specific handling and URL loading mechanism. But one step after another.

I guess you know that a socket server isn't a real problem. We wrote our own "generic" socket server some years ago, for JVx and it's not tricky. In principle, it works like this snippet:

The problem is that you need a sort of protocol for the content. We've used our UniversalSerializer and send simple POJOs. The stylesheet POJO contains the css file as byte[]. Here's our server code:

We add custom stylesheets with remotecss as protocol. The resource loading mechanism of Java(FX) tries to load the URL automatically. The protocol isn't a standard protocol and so we had to create a custom URL handler. The problem wasn't the handler itself because it's straight forward:

And the CssURLConnection also wasn't a problem:

The problem was that the JVM didn't know how to load remotecss:// URLs because it doesn't have a default handler. The JVM offers different solutions for this problem and the well known is:

But this is a static mechanism and we didn't know if another library uses the same method. There's no getURLStreamHandlerFactory in URL and the solution wasn't good enough for us. For a simple test application this restriction shouldn't be a problem, but we didn't like it because we're framework developers.

There's another solution for the problem, because the source code of URL contains the static method:

This method tries to load protocol handlers automatically, if definded via system property java.protocol.handler.pkgs or from package: sun.net.www.protocol.protocolname.Handler

After reading the source code, we found a blogpost about this feature, read more. It was easy to search with the right keyword after we knew the solution.

...be careful with security manager, but this shouldn't matter.

The URL implementation for Android is a little bit different because but if you set the system property, it'll work as expected.

The hardest parts were done and the last thing was the file watcher client because we planned to send the changed CSS file(s) to the app automatically. Here's our solution (Java8 style):

The source code examples aren't complete but I guess you can implement your own solution based on them. We made tests with iOS, Android and Desktop applications and didn't have any problems. The CSS editing feature would be a very useful extension for ScenicView but it's not available right now.

Our test devices:

CSS hacking - test devices

Some weeks ago, Gluon released the first version of their Eclipse plugin for creating/building mobile applications with Java(FX).

We had some experience with their NetBeans plugin but our preferred IDE was Eclipse. So, an Eclipse plugin was good for us
The NetBeans version worked without bigger problems and we expected the same quality for the Eclipse plugin.

We followed the official installation instructions and didn't have any problem. But the problems started after we tried to create Android or iOS specific code. It wasn't possible to access javafxports, android or robovm classes, because the jar files weren't found. The classpath with NetBeans had references to all libraries, but the Eclipse project didn't have such references.

We tried to find some information in the documentation and found the NFC example application. The build file had additional dependencies for android and javafxports. We changed the build file of our Eclipse project:

and after some Gradle/Refresh Dependencies, Refresh All clicks, all Errors were fixed!
It was horrible, because after clicking Refresh Dependencies, nothing happened and after some more clicks, all errors were gone. Not sure if this was a Gradle project problem, or Gluon plugin problem.

Our full build script (without robovm):

• Enable developer options for your Android device
• Show log messages from your Android device: \platform-tools\adb logcat

I wrote a blog post about JavaFXPorts and Android some weeks ago.

At last Eclipse DemoCamp in Vienna, Tom Schindl asked me about the startup performance on iOS, because his experience with startup performance was horrible with early RoboVM versions. I had no answer because we didn't test our app with iOS and... the question didn't get ouf of my head. Sure, I knew that RoboVM was tuned in last two versions but didn't test it myself.

So, yesterday I had the time to test it out and... Startup and overall performance was same as on Android device!
The iOS device was an iPad Air2 and Android device was Nexus9. The performance may be worse on older devices.
Performance? Application start was finished after touch event (< 1 sec).

My test wasn't as simple as expected because RoboVM has some specifics and iOS needs code signing in order to run an app on real hardware. Also my JVx library (jvx.jar) wasn't usable because it contained SwingUI and one class of it was accessing a member of a parent class:

The listenerList is a member of JComponent:

But the member is not available in RoboVM' phantom class. The solution was easy: Removing SwingUI from jar.
A nice feature for RoboVM would be an ignore list of classes/packages.

Here's a picture of our DemoERP application on iOS:

DemoERP on iOS tablet

It's working but still, a Desktop application 1:1 on a tablet isn't the best idea, e.g. the device type (iPad) or WLAN icon is over the application menu. The iOS port has some problems with TextFields, but we'll report an issue.

Thanks to JavaFXports the creation and deployment of our JavaFX app was super easy!

We've good news for you. Since our JavaFX UI has reached version 1.0, we thought it might be a good idea to integrate the UI into VisionX. It wasn't that easy because JavaFX needs Java8 and VisionX runs with Java7. It wasn't enough to switch the JVM because VisionX had Eclipse JDT under the hood and the used version wasn't Java8 ready and also some other libraries had problems with Java8.

It was a lot of work to support JavaFX but now it's done. We have Java8 support in VisionX and all referenced projects were updated. We don't have a public version for you right now because the new features need some additional tests. But we're very happy with the current status. Our development version is very stable and all features are still working.

We have a short screencast for you:

We're happy to announce that our JavaFX UI 1.0 was released.

The release contains all planned features and some more. We have the complete MDI implementation, Zoom support for windows and the scene, a custom scene style, custom comboboxes and much more.

MDI control		Combobox

Styled Scene

Table format (cells)

Zoom

Master/Detail with Tables and Tree

All custom controls are available as separate library, JFXtensions. This library will work without JVx because it has no dependency to JVx. Simply use our MDI implementation or zoom feature for your own JavaFX application without using JVx.

Jar files are available at SourceForge or Maven central.

Our next steps?

We'll integrate the UI in our product VisionX to allow Live Preview with JavaFX. The first update release with version number 1.1. will contain smaller bugfixes and improvements based on user feedback.

So, send us your Feedback if you use our library.

We got great feedback about our first beta release of our JavaFX UI. Many of our ideas were right but our comboxes weren't good enough. We had missing features and some technical problems. One missing feature was: Live search in comboboxes with list of values. Our old implementation of comboboxes was like this:

Combo Box

Our implementation didn't support live filtering, e.g. if you typed a key, the list wasn't shortened...

One problem with this feature was JavaFX' focus handling and popups. It was tricky to keep the focus in the right editor and to keep the popup open or to re-open the popup after every keypress. We had a solution but it was too dirty. So we tried to find a better solution. We moved the the editor in the popup, to avoid focus problems. We had crazy effects with two blinking cursors in two different text fields, very strange.

Our current solution is this:

Filterable combobox

The design is not perfect but we're working on it. The good thing is that we have no problems with focus and filtering is already working. Here's a screenshot of our date editor:

Date editor in combobox

Our date editor needs a small redesign but it's working. The optimization was planned for release 1.1

If you're interested in our current state, check the source code. We're looking forward to your feedback!

Our code is open source and we still have a separete lib (.ext) for all custom FX controls. The UI implementation for JVx is based on this library. So we have JVx independent JavaFX extensions and our JVx UI implementation.