Bundling Java applications for Mac OS X Catalina

Disclaimer
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:

1. 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

2. My application ran as a ‘naked’ 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.

3. When I copied the 1.6.0.jdk directory from another machine into the JavaVirtualMachine directory (just dragged and dropped it all over — needed an admin password) it ran from the packaged app as shown below.

General Point: Apple’s 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 haven’t made the jump to 64-bit. These include… the old Apple-maintained Java 6 Runtime…

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 Apple’s legacy Java SE 6 does run under Catalina.

A solution for the developer — 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 can’t 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 ‘informs’ 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 — on GitHub.

This latter seems to be the way to go, and I will update this answer when I have tested it.