This is a provisional answer to my own question, which I will not accept until I have finally tested it. However, as people are encountering various problems with Java apps on the Mac I thought it useful to post to help others and allow suggestions for improvements.
Reason for the Behaviour Explained
It turned out that:
The reason that my application failed to run was because the Catalina update had removed the Java SE 6 Runtime from the JavaVirtualMachine directory where it resided on a machine running an earlier version of Mac OS X: /Library/Java/JavaVirtualMachines
My application ran as a xe2x80x98nakedxe2x80x99 jar file because there was a copy of Java 1.8 from Oracle in that directory which Jar Launcher (the app that handles jar files) must have employed.
- When I copied the 1.6.0.jdk directory from another machine into the JavaVirtualMachine directory (just dragged and dropped it all over xe2x80x94 needed an admin password) it ran from the packaged app as shown below.
General Point: Applexe2x80x99s legacy Java SE 6 Runtime does run under Catalina
There is an article on Ars Technica that states:
And a few longstanding components of macOS havenxe2x80x99t made the jump to 64-bit. These includexe2x80xa6 the old Apple-maintained Java 6 Runtimexe2x80xa6
This had suggested to me (as also the kind comment by @greg-449) that the Java SE 6 Runtime was 32-bit. However I found a thread on the MacRumors forum about the different problem of Catalina preventing installation of Java SE 6 Runtime for a commercial app that requires it. When that was eventually overcome, the app worked. This was what caused me to check things out, confirming that Applexe2x80x99s legacy Java SE 6 does run under Catalina.
A solution for the developer xe2x80x94 replacing the JavaApplicationStub?
To re-emphasize, I am concerned with delivering a Mac app that just works after the user has performed an easy Java install. I canxe2x80x99t expect him to fiddle around trying to install the legacy Java 6 runtime to get my app to work.
It would seem that it is the JavaApplicationStub (in the application bundle) that xe2x80x98informsxe2x80x99 the system where the Java runtime is to run the application. Originally this could be handled for the developer by a little Apple utility, jarbundler, which never worked with Oracle Java runtime. (Thanks @abc for reminding me of this.) However it turns out that there have been ways round this problem, as described on this Stack Overflow post, and there is a replacement for JavaApplicationStub: universalJavaApplicationStub xe2x80x94 on GitHub.
This latter seems to be the way to go, and I will update this answer when I have tested it.