DefaultScriptService: do not wrap JSR-223 engines

In theory, it was nice to try to expose all available JSR-223
ScriptEngineFactory implementations as SciJava script languages.

However, without an associated explicit ScriptLanguage plugin,
there are limitations to what the SciJava framework can achieve.

And there was related behavior which could be construed as a bug:
each SciJava scripting component now exposes its ScriptLanguage as
a ScriptEngineFactory via the javax.services mechanism so that it
can be used from other JSR-223 applications not built on SJC. This
caused them to be discovered and added to the ScriptLanguageIndex
twice: once as ScriptLanguage plugins directly, and again as
wrapped JSR-223 ScriptEngineFactory implementations. While we could
make the ScriptService smarter about this situation, it is easier
to simply stop wrapping vanilla JSR-223 ScriptEngineFactory
classes, because we have no use cases relying on it. (The only
engine I know of which has no associated SciJava scripting
component is AppleScript on OS X, and AFAIK, no one writes
AppleScript scripts in anger in ImageJ.)

Author: ctrueden

src/main/java/org/scijava/script/DefaultScriptService.java

@@ -346,20 +346,6 @@ private synchronized void initScriptLanguageIndex() {
 			index.add(language, true);
 		}
 
-		// Now look for the ScriptEngines in javax.scripting. We only do that
-		// now since the javax.scripting framework does not provide all the
-		// functionality we might want to use in a SciJava application.
-		final ScriptEngineManager manager = new ScriptEngineManager();
-		for (final ScriptEngineFactory factory : manager.getEngineFactories()) {
-			index.add(factory, true);
-		}
-
-		// Inject the context into languages which need it: the
-		// wrapped engine factories from the ScriptEngineManager.
-		for (final ScriptLanguage language : index) {
-			if (language.getContext() == null) language.setContext(getContext());
-		}
-
 		scriptLanguageIndex = index;
 	}