After this year's JavaOne, I spoke with Johan Vos, CEO of Gluon, a cross-platform Java API for creating mobile Java apps. They created a JavaOne app for 2015 and 2016, and won the "Duke's Choice Award" for 2015 and 2014 at the conference.
1. How Did You Like JavaOne This Year?
Every year, JavaOne provides a great opportunity to get in touch with Oracle, other companies, and members of the Java community, and to share the latest evolutions and ideas in Java. This year was no different.
I talked to a lot of people, saw great presentations and learned about new technologies. As most JavaOne attendees will recognize, the hallway conversations are the most important part of the conference. The amount of innovation and knowledge per square meter is fabulous at JavaOne. Like every year, after one day I already had more than enough ideas to try out for the next year. Now that I’m back in the office, a large amount of the work we are doing is just prioritizing everything we have to do!
Personally, JavaOne this year was the busiest for me yet, as I did a walk-on in the Java Strategy Keynote on the Sunday, where Anil Gaur, Group VP at Oracle asked me on stage to talk about how the community could collaborate on the upcoming Java EE 8 and Java EE 9 standards.
I participated in 6 sessions, and I had a role in the JavaOne Community Keynote as well, where I explained the importance of Java on Mobile and Embedded.
2. What Was the Background Behind Developing Gluon?
In 2013, I started working on JavaFXPorts (http://www.javafxports.org), which is a port of the JavaFX platform to mobile devices (iOS/Android). It soon turned out to be a very viable and interesting option for cross-platform mobile development. In fact, it was the missing link towards having the WORA paradigm on mobile.
There were 2 main reasons on why I co-founded Gluon:
We come from an open source background, and we see open source as a great way to get closer bonds to the community. At the same time, we are convinced that there is a great match between open-source development and commercial product offerings. They both leverage each other, and add value. Developers need to be able to work with great open-source software, and companies need to be able to get first class products and supports for those great technologies. Hence, we needed a commercial company backing and extending JavaFXPorts.
JavaFXPorts is about having JavaFX on Mobile, but there are 2 other important requirements in order to have an end-to-end solution: a slick UI toolkit, and a connection to the enterprise/cloud systems. Those two missing parts lead to the development of Gluon Mobile and Gluon CloudLink.
Using Gluon Mobile, developers can use their favourite IDE to create highly polished applications that have a Material Design look and feel, access to all native services / hardware on mobile systems, and that can trivially connect to the cloud. Gluon Mobile enables applications to be truly write once, run anywhere.
Gluon CloudLink on the other hand allows for the seamless synchronization of data between mobile devices and enterprise/cloud systems. Also Gluon CloudLink provides enterprise functionality as accounting, analytics, user management, localization, etc.
We are in essence providing a full stack solution — write one application in Java using Gluon Mobile, and it will run on top of JavaFXPorts on iOS and Android with no custom UI code or platform-specific code. At the other end of the stack, Gluon Mobile can talk to Gluon CloudLink to synchronize between different mobile users, the cloud, and other backend systems / external clouds.
People who pigeon-hole Gluon to simply being a provider of a mobile API are severely underestimating the depth of the Gluon offering.
3. How Has the Java Community Responded to Gluon?
It was great to see how people liked the JavaOne Community app that we developed. As we noted in one of our sessions, this project was non-trivial in that it used a number of hardware features on iOS and Android, involved approximately 24 different views. More impressive however is that despite the requirement for large amounts of native integration, because of Gluon Mobile we didn’t have a single line of platform-specific code! We simply used the cross-platform APIs in Gluon Mobile to access the native services in a platform-agnostic way.
There was another benefit to us too: in building out this application (which itself was an extension of the same app we did for JavaOne 2015), we built out a huge amount of new functionality in both Gluon Mobile and Gluon CloudLink. These will be made available in our upcoming releases for both of these projects.
It was also very rewarding to hear non-Gluon people talk about our technologies. It is nice to give a presentation on your own technology, but it is even nicer to attend presentations from other people that talk about Gluon. We attended a number of sessions where Gluon was mentioned, and given how some presenters spoke, we felt a little guilty — it sounded like a paid advertisement for Gluon — but in reality people love our APIs and solutions, and we love our early adopters. They take the risk with Gluon, and are rewarded with high quality applications that are cheaper to make and support, and they are now our biggest champions.
Some sessions that in particular blew us away was the amazing work of Paul and Gail Anderson, who presented a tutorial on how to create applications using Gluon Mobile, and Sean Phillips, who showed how NASA is using Gluon Mobile for planning future space missions.
I think Java developers really like the fact that they can now use their existing Java knowledge to create high-performance and visually attractive applications using their favourite IDE, without any compromise. The fact that they can build a single application for multiple platforms means that their development effort can be halved, and that there is no need for multiple development teams (or developers that have both Swift / Objective-C and Java skills).
4. There Have Been Concerns About Oracle’s Stewardship of Java Since the Sun Acquisition. What Are Your Thoughts?
We should make a difference between Oracle as a company and Oracle as the Java steward. Oracle as a company makes their own decisions. I may like it or not, but they decide for themselves how they want to use Java in their products. What is important, though, is that Oracle as the Java steward also has a responsibility towards the broader Java ecosystem. If the Java community has a large interest in a specific technology, Oracle should at least allow for the community to explore and enhance that technology, even if it is not of interest in their own product pipeline.