File	Date	Author	Commit
FileReadTest	2024-09-05	R. Diez	[05ddb6] Upgrade application version numbers to 1.33
JavaCommon	2024-09-06	R. Diez	[3ae7af] AboutBox, LicenseBox and HistoryBox: Increase t...
PerlScript	2020-06-29	R. Diez	[ac3021] Perl script: Calls to flush() can fail.
QuickDiskTest	2024-09-06	R. Diez	[3ae7af] AboutBox, LicenseBox and HistoryBox: Increase t...
.gitignore	2023-05-20	R. Diez	[24fa1b] Small improvement in .gitignore
README.txt	2024-08-06	R. Diez	[60ecb7] Distribution build script: Optionally build jus...
build-distribution-for-windows.sh	2024-08-09	R. Diez	[1025d3] The build script now shows the absolute paths o...
pom.xml	2023-05-18	R. Diez	[733e78] Improve comment about Maven's <debug> and <debu...

Read Me


--- Developing the Java Applications ---

I normally develop the Java applications with NetBeans 22 on Linux,
newly with VSCodium too.

Up until commit ac3021c4edebb7d3d43bf4bb50506f87258de9be the Java code used Ant-based NetBeans projects.
But now all projects use the Maven build system. I decided to switch to Maven for the following reasons:

- NetBeans Ant-based projects are not completely reliable.
  In my experience, sometimes you modify a constant in a source file, and other affected Java sources
  in the same package do not get recompiled.  A manual 'clean' does the trick, but that is no good
  for a build system.

- No transitive dependencies. Say you add a JAR, like the JNA library, to the JavaCommon project.
  You will then need to add the same JAR to all applications that depend on the JavaCommon project.
  That does not scale if you have many dependent projects and you want to upgrade a JAR in JavaCommon.
  This issue is not a problem yet for these particular projects, because they do not use
  any third-party JARs yet, but I have other projects where that is the case.

- I always found Ant hard to work with. NetBeans Ant-based projects are missing basic functionality,
  like the ability to generate a single combined JAR for an application. I had to find and modify
  an Ant XML configuration file for that purpose, and that was no fun.

- Support for Ant-based projects does not seem to be further developed in NetBeans.
  In fact, NetBeans recommends Maven now for new Java projects.
  Therefore, any shortcomings in Ant-based projects will probably never be fixed.

- With Maven you are free to use another IDE like Eclipse. You do not actually need an IDE at all
  to build or modify the projects. For example, some people use Emacs to develop in Java.
  NetBeans has long-standing issues and its future does not look rosy, so my long-term plan is to migrate away from it.

The trouble is, the GUI forms have been developed with NetBeans' Swing GUI Builder (formerly Project Matisse),
see the .form files in the repository. If you edit the corresponding Java source code by hand, the .form files
get out of sync and are rendered useless. Therefore, if you want to keep using the Swing GUI Builder,
you are tied to NetBeans, at least when visually modifying the GUI forms.

This dependency on NetBeans bugs me. To make matters worse, I find the Swing GUI Builder not particularly
intelligent or user friendly. For example, it does not even support 2-way form designing, like Borland Dephi did.
I already had to manually redo all forms once, because support for SAF (Swing Application Framework) was
dropped, and I did not manage to perform an automatic conversion, see for example commits
641e51f06a45b0afa2d372ce71faf69022c31b7f and 18672f93ef9eb1752aa44b57c4fa94a5e8508aae.
It serves me well for trying to get the comfort and productivity of Borland Delphi's or Visual Basic
(we are talking year 1995 here) in the open-source Java world (as of year 2020).
After similar trouble with FXML in JavaFX, chances are that I will never use a visual form designer for Java again.

In retrospect, I am not sure whether migrating to Maven was a good idea either. It has its long-standing issues too.


--- Building a Release---

When working within NetBeans, there is an extra JAR for JavaCommon, and the JARs are not compressed, in order
to reduce the time it takes to build and debug the applications.

Use script build-distribution-for-windows.sh in order to generate a binary release.
The release will bundle a Java runtime for Windows, so that the end-user does not have to download
and install one separately. The generated application JARs inside the release bundle have all dependencies
combined, are compressed and have no debug information. You can take those JARs from the bundle and use them elsewhere
(like under Linux). This fact is also stated in the release bundle's README.txt file.