Created earlier this year to fill the void Oracle left when they withdrew installer provision for application interface designer Scene Builder in JavaFX, Gluon has since gone far beyond its initial remit. Last week, in addition to its current roster of offerings (the Gluon Charm Library, Gluon Cloud, and upcoming library sub-component Gluon Glisten), the company officially rolled out the Gluon Store, allowing users to buy licences and help support the initiative. On top of this, August 3rd marked the official rehoming of JavaFXPorts from LodgON to Gluon. We caught up with co-founder Johan Vos for some background on these happenings and discussed what he believes Gluon represents for the JavaFX ecosystem at large.
Voxxed: How happy are you with Oracle’s commitment to JavaFX?
Vos: I make a clear distinction between Oracle, the Java steward, and Oracle the commercial company. Being the Java steward, Oracle dedicates resources to JavaFX. There are a number of excellent engineers working on JavaFX. They do a great job, and they are very approachable. Oracle created the OpenJFX project, which is a great environment for Oracle engineers and third party developers to work on and discuss JavaFX.
As a commercial company, Oracle seems to show less interest in creating business with JavaFX. They have other products in that area and they probably focus on those. But that’s OK as the commercialisation is now done by Gluon 🙂
Why is Gluon so committed to the JavaFXPorts project?
In summary, we believe an ecosystem in today’s IT industry needs to combine open-source efforts and commercial services and support. The requirements of the commercial services and the capabilities of the open-source code need to be aligned well. Gluon provides services on top of JavaFX, which is the Java Client API. Since more and more people and companies are using mobile phones and tablets to get information, place orders,… it is important that JavaFX runs on those mobile devices as well. This is taken care of by JavaFXPorts, which is an open-source project. Today, open-source projects are only successful if there are companies that depend on them, as that often implies they also fund the open-source development.
Gluon depends on JavaFXPorts, and mainly funds JavaFXPorts. Vice versa, JavaFXPorts depends on commercial companies like Gluon as they invest the resources in it.
You say you’d like to see the ecosystem expanded – what sort tools do you think are most badly needed, and are there any projects out there you’ve got your eye on?
The more services, the more choice for the customers. Also, the quality increases since developers want to provide the best possible service. There are already a growing number of tools and services in the JavaFX world, e.g. jfxtras, e(fx)clipse. Apart from Gluon, there are some commercial products like FlexGantFX.
Why is the GluonHQ store such an important step for the JavaFX ecosystem?
About 1.5 years ago, I started to work on JavaFXPorts. It was a non-trivial task to get JavaFX running on mobile devices in such a way that we consider it production-ready. Now that we have the Gluon Store, the open-source offering is extended with a commercial offering.
Over the past few months, we’ve received an increasing number of requests from developers and companies that want to pay for services. With an open-source product only, it is hard to guarantee support, as the effort is often done in spare time. Now that Gluon offers subscription models and products, the whole JavaFX offering becomes much more professional. We can now fulfil the needs of companies that require commercial support for all open-source tools they use.
What are the key things you are trying to achieve?
We want developers to be able to create compelling end-to-end Java Client applications, that run on desktop, tablet and phones. Developers should be able to spend their time on their particular use case, instead of having to write the same boiler plate code over and over to achieve things like data persistence and synchronization. We want Java Enterprise developers to be able to work with JavaFX and create real nice applications without a steep learning curve. Also, we want JavaFX applications to look great on mobile devices. We want to make it easy for developers to create user interfaces that look very familiar to users of mobile phones and tablets, without requiring those developers to become user interface experts for the different platforms.
How did you come about with the business model for the Gluon Store?
When JavaFXScript was announced in 2007, I really liked the idea of a client-originated Java framework. But I also realized that there were a number of requirements before this could be a success: it had to work on mobile devices, and it should be easy for the typical Java developer to create applications that look great, and to deploy them on mobile devices. I even bought two HTC Diamond phones that were preinstalled with JavaFX!
The business model is clear: provide services and products that allow the almost 10 million Java developers to write client-backend applications in their favourite language (Java!) without having to rewrite a user interface for every single target device. Java is very strong on the server, and we should leverage that position when doing client-side work.
The business model is not that surprising. However, someone has to do it. There were a few loose ends in the original Sun and later Oracle offering:
- No framework that connects the JavaFX client to existing backend and middleware
- No official support for mobile…
- And by extension, no support for typical mobile UI development.
At LodgON, we were already working on RedFX, a framework that synchronizes state between different Java clients and a Java-based backend and on DataFX, allowing to retrieve data from backend servers in a JavaFX friendly way. That tackles only the first loose end though. Fortunately enough, the ControlsFX founders had the same opinion on how to create a business model with JavaFX, and they have lots of expertise with developing UI controls that are targeting specific domains (e.g. mobile). The remaining part, support for mobile, is what we tackle in javafxports.