jalview

This is likely an improvement on the "roll your own" pattern of setting Runnable handlers for dialog responses as hacked together for JalviewJS (JAL-3048). If so, it would be preferable (but no small job) to change all dialogs to this pattern.

There are still numerous dialogs that have not been changed to either pattern (so won't work in SwingJS): see comment at https://issues.jalview.org/browse/?focusedCommentId=20525&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#JAL-3048comment-20525.

Class has some compiler warnings which could easily be resolved (typed Hashtable, unused import).

It would be good to add Javadoc to this method

As an aside, I would suggest inlining (removing) the two overloaded constructors that call this one (to reduce code bloat).

'var' is since Java 10. We are still supporting Java 8 runtime which will not run this code (sadly).
Compile with JDK 8 to find other occurrences (also Preferences, line 596 is not Java 8 compatible syntax).

Above statement is a duplicate - should only be inside the check for service != null. It fails with NPE if service is null.

startjob and canceljob are only referenced in jbinit() so should be local variables in that method.

Field startJob used to be the return value of showRunDialog(). As it no longer is, it can be removed.

Agree this is just touching on a much bigger task.
However...
The reason I /needed/ to do this rather than just /wanted/ to do this is that several of the classes I've been working on (e.g. jalview.bin.Launcher, jalview.bin.HiDPISetting, jalview.bin.MemorySetting) run very early on (especially jalview.bin.Launcher!). This means Cache.log has perhaps not yet been initialised, so a Cache.log.debug doesn't log (unless you count reams of NullPointerExceptions as logging!).

In the case of HiDPISetting and MemorySetting that also get used in Getdown, where there is no jalview.bin.Cache, they currently have to use System.out and System.err [or maybe I could stub jalview.bin.Cache too]. I'd prefer them to use Cache.log when they can so this is an attempt at starting to decouple jalview.bin.Cache from other jalview things so it can be used standalone within Getdown. The main reason for wanting to do that is to have shared code to read the preferences between Jalview and Getdown.

Ben Soares as far as I can see the only thing missing after this branch is merged to develop is this logic. I just did a quick test and it appears 'Platform.isAMac()' returns false under JalviewJS, so probably not a dealbreaker. Do you agree ?