I’ve been using QtCreator and the QtFramework for many years to build apps for Windows / Linux. Deployment is always a struggle with the Qt Framework. Deployment is hard work. Lots of hand work and testing to make sure the installers are correct.
I’m now forever done with Qt for that. Java is sooooooo much easier to deploy.
The above shot is of the prototype Java Impress Show Runner app running on Linux from a JAR file built on Windows 10. It runs on Windows 10 and it runs on Linux, with no changes and instantly. No fiddling required.
Here’s what it takes to build apps this way. Just an overview, not the entire story, but it has only been Five days since I started with Eclipse and Java. So it’s not that big an effort.
Using Eclipse for Development
This is not a tutorial about how to write Java or use Eclipse, but a short review of the back end of the process, comparing Qt / C++ with Eclipse / Java. Here is a summary list of the two environments:
QtCreator / C++
- Available for lots of platforms including Windows, Linux, and Mobile devices.
- Uses C++ as it’s primary language. Supports others too.
- Has a very nice Gui Building Framework with drag / drop GUI building.
- Completely “Old School” for deployment. Very little in terms of tools with long complicates “scripts” built for you to manually execute to build the installers for any platform.
Eclipse IDE / Java
- Available for lots of platforms including Windows / Linux and Mobile.
- Uses Java as it’s primary language. Supports others too.
- Has a pretty nice Gui Building Framework as a plug-in called Window Builder. The downside is that it supports a large number of “Layout Strategies” and they are very complex and not intuitive to use. Bummer.
- Completely modern for Deployment to any platform. A simple export dialog creates a JAR file, which is a ZIP file of the Java classes of the application and any dependencies / resources. This JAR file will run on any “Desktop” environment.
Eclipse Export Process
Here are some screenshots of the Export process to build a JAR file for my program:
Choose File Export… and choose Runnable JAR File.
Now choose Launch Class Containing the Main entry point.
That’s it. Copy the JAR file to another system with no Eclipse or another architecture or another Operating system and voila! It works! The only thing required is the Java Runtime. Eclipse packages all your “Dependent Classes” into your JAR file so they are there when you run. And it knows, you don’t have to figure it out and manually copy them. It just works. As you would expect, and as Qt does not do. On Qt it’s a completely manual process.
Just works on another OS
I’m not clear why Qt has not done this. I’ve been using the Qt Framework for over 10 years. They have had plenty of time to get off their keesters and build a scheme to automatically and click through method to deploy. They have been lying down on the job as if this were not part of their problem.
It is a big part of the problem and other folks solve it.
No wonder Android chose JAVA rather than C++ as a framework.
Further Work for the Application
The Java Impress Show Runner app has come a long way in five days. The file open / save dialogs are done to pick shows, put them in a list, reorder the list, save and restore lists of shows and save and restore the defaults of the program. Here are most of the remaining tasks:
- The app needs to launch shows, and click the mouse until they end and see them end to launch the next show in the list. I’ve not studied the Java classes to do these things.
- Clicking the mouse is solved for Windows and Linux. If I can launch an app from Java, then I can launch “xtodo click 1” on Linux, and write a simple xtodo.exe for windows and launch that to click the mouse. While the show is running, the app is watching, and launching a mouse click app every five seconds too. The Qt version figured out what to do to click the mouse and I can move that into a simple C++ app that does nothing else.
- With Java it’s easy to condition the code at run time for each OS. Since the same code is running on all OSs, it’s not Compile Time conditionals, but “Run Time” conditionals that you use to deal with different OSs. Neat. So far it’s doing some of that for file separators and paths.
- All the Gui layout is done, but in Absolute or fixed layout. So learning the other layout schemes and choosing one to layout the app so it can be resized etc is something to do after the rest of the job is done.
Problems Did Crop Up
The use of Eclipse / Java was not completely smooth sailing.
Trying to install JDK 14, which I had been using on Windows 10 completely hosed my Linux Mint 19.3 VM. The problem is that the lawyers apparently added a special thing at the end of the install to “Accept” the license agreement. But they did it in a way that did not work on Linux Mint, and after terminating the install the system was hosed asking to complete the bogus installation, which of course would not work. So the system could no longer install anything or be updated. No way back. I had to build a completely new Virtual Machine and move what I had to the new one. The solution is to use the default Java JDK 11 rather than JDK 14.
I then tried to move my Windows 10 system back to JDK 11 and that was problems for Eclipse. After Manually Editing the eclipse.ini file, I finally got that going, but then realized something. Perhaps it’s not necessary to back up to JDK 11. Apparently you can choose to use the JDK 11 interfaces from inside the JDK 14 installation. So I think I didn’t need to back up to deploy an app on JDK11. Just change the settings and build the app for JDK11 interfaces and behavior. Oh Well. I think that’s right anyway.
The app, built on JDK 11, worked fine on another Windows 10 system with JDK 14 installed.
The problem is that there are too many places scattered around that you need to set this version level. And if you miss one you get errors that don’t lead you the place to fix right off the bat.
But it’s all working now.
Ok, back to work. Break time is over. I’ll never look back.
May you walk in the light of the Crystal.