CR-JAL-181

Also covers some untagged commits including
425ed088 VARNAPanel change field _border (used by JSComponent) to _myBorder

• comment "how to avoid this?" - answer might be a CheckStyle rule that flags an error for a field of this name in a class that extends Component?

b2f46d31 AppletParams
4b022090 JalviewAppLoader
08873667 Preferences and other classes

May need some thought as to intended scope of the various singleton classes affected.
For example ScoreModels : provides the built-in models including BLOSUM62, PAM250.
Additional models can be added by drag and drop (e.g. of resources/blosum80.scm).
Should doing this in one applet make it available to all? In which case true singleton scope is what is wanted for this class.

Could the need for public fields in Instance be avoided by a modified pattern:
1) rename Instance as InstanceProvider
2) give it only static fields and methods

public class InstanceProvider {
   private static final String JAVA = "Java";
   private static Map<Object, Map<Class, Object>> instances = new HashMap<>(); // 'singleton' for each class, per context
   private static Object getContext() 
   { 
      // returns JAVA for Java, currentThread.getThreadGroup() for JS
   }
   public static Object getInstance(Class c) 
   {
      return instances.get(getContext()).get(c); // with check for null
   }
   public static void setInstance(Object o) 
   {
        Map<Class, Object> map = instances.get(getContext());
       // create new Map if null
       map.put(o.getClass(), o);
    }

Client code pattern:

public FeatureSources getInstance() 
    {
        FeatureSources instance = (FeatureSources) InstanceProvider.getInstance(FeatureSources.class);
        if (instance == null) 
        {
            InstanceProvider.setInstance(instance = new FeatureSources());
        }
        return instance;
    }

Advantage: extensible without any code change (no need to add a field to Instance for every new singleton class).

One thing to think about is what would be the simplest and most natural way of calling for the singleton from other classes. Right now it is set up so that if there is a singleton class, all references to that class go through the class's static getInstance() method:

findQuality(0, maxLength - 1, ScoreModels.getInstance().getBlosum62());

To me, that has a nice look to it, so I would hope we stick with that.

If it's OK with you, I would like to table this issue, make sure we have the tests successful, merge the branch, and then think about refining it. I need to make sure I have any applets running right now.

We will need clarity on behaviour of copy and paste. Jalview uses both
Toolkit.getDefaultToolkit().getSystemClipboard() // this has global scope
and
Desktop.getInstance().jalviewClipboard // this has per-applet scope
with the latter 'overriding' the former.
This may be fine as is, or may create some puzzling behaviour e.g. a "rich paste" (sequence + features) within an applet and a "text paste" (sequence only) across applications.

I am seeing some odd z-plane behaviour, not sure if it is specific to this branch. If the desktop is brought to front, I can't then bring any other panel to front.

Too much change around ASequenceFetcher, DbRoot etc to be able to review from the diffs. They seem to work when testing!
(The code here may now be overcomplicated for the simplified (post-DAS) world.)

I have added a large number of commits to this review which were tagged "JAL-3253-applet" or "Jalview-JS/develop-3253" or similar. This should be just the issue id for JIRA to associate the commit with the issue.

I suggest we close this. It's all ancient history now.