Set the ScriptEngineManager to use Context's loader

[gselzer]

This change fixes the issue of ScriptLanguage plugin creation in imagej/napari-imagej#58.

The singular change changes the way in which AdaptedScriptLanguage's ScriptEngineManager is constructed. Previously, the no-args constructor was called. Now, we call the constructor taking a ClassLoader, and pass a Context.getClassLoader().

new ScriptEngineManager() does nothing more than call new ScriptEngineManager(Thread.currentThread().getContextClassLoader()).

Context.getClassLoader() is nothing more than this call with a fallback for a null ClassLoader

Thus, this change does nothing more than ensure that ScriptEngineManager has a ClassLoader, avoiding the internal fallbacks.

The only functionality we may lose is within ScriptEngineManager.getServiceLoader(ClassLoader c). Here is the method, decompiled in IntelliJ:

  private ServiceLoader<ScriptEngineFactory> getServiceLoader(ClassLoader var1) {
    return var1 != null ? ServiceLoader.load(ScriptEngineFactory.class, var1) : ServiceLoader.loadInstalled(ScriptEngineFactory.class);
  }

This PR will ensure that var1 is always non-null. Thus we lose any situations where we called ServiceLoader.loadInstalled. But, seeing as how this method [always ignores Service Providers in the application's classpath], I don't think we ever want that behavior here? When would we ever want to avoid loading a ScriptLanguage that is on the application's classpath?

Do you have any concerns @ctrueden?

[ctrueden]

@gselzer Thank you! No concerns, I think this fix is exactly correct. 👍