The focus of their application is on training and resource management for companies in the aviation industry (airlines).
MINT is actually the reason why I got involved in JavaFX development. In early 2013 they asked me to create a version of FlexGantt for JavaFX. Until then only a Swing version existed. When they first approached me I was somewhat resistant to sign up with them because of what I had heard about JavaFX until then. But once I got into it I quickly became a JavaFX enthusiast. Why? Because I had the luxury of working with version 8 from the very beginning. I can not blame anybody who didn’t like versions 1 and 2, but 8 is a completely different story.
Especially interesting from a JavaFX point of view is the fact that this application is very big and also that it is a successful migration from Swing. The following images show the JavaFX version of the application in action:
The following are the answers MINT sent me for the questionnaire I sent them recently. I hope that their answers will be helpful for others when they need to make a decision on whether to go with JavaFX or not.
What is the name of your product / project?
MINT Training and Resource Management System (MINT TRMS)
Who are your users / customers?
Training departments of airlines, technical facilities and production companies in the aviation and other training intensive industries.
What is the purpose of your software? What are its benefits?
The MINT training solution provides powerful tools for records and skill management, training planning and scheduling, electronic online and offline grading and e-learning.
Is the application operational? If yes, since when. If not when do you plan to go live?
Yes, JavaFX first appeared in the application in 2013 but earlier versions of the software are available since 1998.
How did you get the necessary JavaFX Know-How into your team? (Consultants, Internal / External training courses)?
Initially we did a pilot project to migrate selected Swing UI to JavaFX. Later on there was some internal training to spread the knowledge. See also Oracle Case Study about this.
With which version of JavaFX did you start? 1, 2, 8?
When did you start developing the application and how long did it take?
The migration from Swing to JavaFX started in 2012. It is an ongoing process. A turning point was in 2014 when the main window finally could be moved to JavaFX.
How many developers worked on it? In total and on the UI.
Work is done by 8-10 developers working on the UI and backend.
How big is the application? Lines of code, Number of classes.
1.8 million lines of code, 6300 classes.
How big is the JavaFX client? Lines of code, Number of classes.
1.1 million lines of code. 4800 classes. This includes remaining Swing parts.
Why did you choose JavaFX as frontend technology? And very importantly: why did you not choose HTML / Web?
Coming from a Swing rich client it was a natural move to switch to the JavaFX successor. With FX the UI got a modern look and feel, smooth animations, and hardware acceleration. Regarding technical aspects, with observable properties and bindings the JavaFX API is easier to use with less code. And with FXML and CSS we can keep the UI building out of our code and focus on the business.
Moving all of this to the Web would be a huge effort. At the same time we keep supporting Web and mobile users with a responsive web application, providing access to most commonly used features.
Was it difficult to convince decision makers to agree on JavaFX?
No. Ultimately it was a management decision in the first place.
What were the biggest challenges / problems / issues / bugs you faced in the JavaFX part and how did you solve them?
Operating on the cutting-edge of JavaFX development can be difficult. Especially when we started with JavaFX 2 we faced several bugs, some of them specific to a platform or to WebStart. They were reported to Oracle but we still needed to find workarounds because an official fix could take 6 months or longer. It also was a challenge to get JavaFX 2 working on all platforms via WebStart because it required a separate installation.
Today with JavaFX 8 things got easier. Swing integration is still a problem. And we have to pay a lot of attention to Java 8 update releases. Frequently we cannot support the latest update when it gets available, and once we support it we may not be compatible to the previous versions anymore.
Which 3rd-party products / frameworks / tools (open source and commercial) did you use and why did you choose them?
In terms of JavaFX related 3rd party products, we use ControlsFX because of high quality controls with good documentation and a close connection to the Oracle JavaFX team. And we use FlexGanttFX which was developed as a joint-venture with Dirk. The Swing-based predecessor FlexGantt was a core component in our product and we needed the same level of quality and flexibility in JavaFX.
Did you mix JavaFX and Swing code?
Yes. This is an ongoing source of issues, e.g. when it comes to drag/drop support, layouting, threading, and window ownership. In particular communication between Swing’s EDT and JavaFX’s application thread is challenging. Both UI toolkits are single-threaded but when they are mixed you have to deal with two mutually exclusive threads.
With a Swing-based product of this size there is no other choice but to migrate it piece by piece which of course mixes JavaFX and Swing.
Would you use JavaFX again for your next project? Please elaborate why or why not. Which recommendations do you have related to JavaFX for other companies / projects?
When a decision is made for a Java desktop or embedded application, my first look would be at JavaFX. It generally is a pleasure to work with and the results are convincing. For specific technical requirements a closer look would be recommended, e.g. compatibility to existing frameworks and controls, low-level access to hardware, 3D capabilities, etc. Also, JavaFX developers may be more difficult to come by but the transition from Swing is not too hard.
Which features would you like to see being added to JavaFX?
- More standard controls, e.g. check combobox and check list view, a tableview with column filters.
- An action framework with standard actions on each control.
- Embedded, custom-control aware and two-way integration of SceneBuilder with Eclipse.
- CSS debugging features.
- Better integration into platforms, e.g. appstores, taskbar / system notifications, OSX menubar.
Do you plan to provide a mobile version of your application or a mobile addition?
No mobile support intended at this time. Our web-application is built with responsive design and works on cell phones and tablets as well. It is certainly an option once the tool chain incl. app store integration is complete and reliable results can be achieved on common devices.