Some Notes on Building a Java application using JavaFX
About 12 years ago I was a Java developer working on some early e-commerce applications for the retail sales industry. Our applications were built using a Swing GUI (Graphical User Interface) and a legacy Oracle Database Management System. All communication took place between client SparcStations and back-end Unix systems through an Open Database Connect (ODBC) interface. In those days, Sun Microsystems owned and managed the language and its supporting environment and documentation. Of course that all changed when Oracle Corporation acquired Sun in 2010 (as a wholly-owned subsidiary). I hadn’t followed these developments too closely; I had moved on and was a Systems Engineer doing Federal Government contract work and had long ago given up on the notion of being a “code pig” for a living.
Almost without exception my career as a software developer was in a team environment, ranging from small groups to large office full of co-workers. Now I was embarking on a self-learning exercise, going it alone on my Microsoft Windows PC at home.
I decided to try out Oracle’s JavaFX as the code base and NetBeans as my Java development environment. I made that decision with a little angst; I’m not a big fan of Oracle Corporation, and I was concerned about their commitment to the language. On top of that I was keenly aware of the security flaws in the Java Virtual Machine (JVM), the run-time environment that is the intermediary between an application and the underlying operating system. When I started this little project in early 2012, there was a nearly continuous stream of JVM exploits and accompanying negative media reports. The Java Standard Edition development kit (Java SE SDK) had transitioned to version 1.7, and the latest JVM was early version 7 and still had numerous issues.
But the Oracle integrated product suite offered some clear advantages, and as the official sponsor of the language I was at least assured of consistency with the language standards. JavaFX adds some useful extensions to the Java Standard and Enterprise Editions (Java SE and Java EE). NetBeans turned out to be a nice package (easier to use than Eclipse, in my opinion) for my development environment. Besides, I wasn’t building an enterprise system; performance and security were not my main concerns. And there are vulnerability issues across all languages, deployments and platforms, so there is no perfect solution out there. I have more to say about this when it came time to deploy the app.
I was also intrigued by Oracle’s SceneBuilder tool; I had some experience using PowerBuilder in the 1990’s and liked the ease-of-use of a graphical layout tool. I also had some recollections of laying out a “Graphical User Interface” (GUI) using Swing libraries…no picnic, to say the least. Oracle has stopped maintaining Swing in favor of the JavaFX GUI libraries and may even deprecate it in the future; a good thing, in my opinion. Since I didn’t have a firm idea of the features I was going to add as I went along, I figured SceneBuilder would allow me to more easily tweak the layout on the fly as I made enhancements downstream.
Finally, I planned to adhere to some basic design principles that experience over the course of many years of software development taught me:
- Separate functional behavior – I would use a simple Model-View-Controller (MVC) pattern to organize the user interface code, the algorithmic code, and the data store code in separate packages. This proved to be a fortuitous decision as I added features over the following year.
- Adhere to basic object-oriented principles, something that comes naturally with Java. I like the basic OO concepts, being able to model a system as a set of inter-related objects that communicate with each other to exchange data, that expose only the methods (functions) that are needed outside their boundaries, that allow customization of functionality through inheritance, and that allow you to establish rigorous behavior requirements through interfaces. But I had to go back and do some in-depth studying when it came time to exploit these capabilities in practice, and I won’t pretend that I wasn’t doing a lot of refactoring as I went along! The code samples in this document have typically seen many iterations (and by ‘many’ I mean hundreds, in some cases).
- Use a “document-as-you-code” approach; this is a discipline that is easily overlooked, especially in the beginning of development, but pays off handsomely going forward – I wasn’t starting with a complete “capabilities list”, I anticipated not being able to work on the app on a regular basis, and I was in a learn-as-you-go mode, especially in the beginning. Taking the time to write class, method, and instance documentation as I went along (well, a little after-the-fact, anyway) paid off many times as I got side-tracked with other life events, or veered off track and had to regroup, a regular occurrence for me, especially in implementing cross-package features. It’s been said that if you don’t understand your own code, how can anyone else? NetBeans provides a Javadoc build capability (from the Run menu) which makes it easy to generate and review class documentation periodically.