Java Reference
In-Depth Information
and printed the language name and engine name. Finally, I printed all the available names
for each factory, which shows all the available aliases that can be used to retrieve them.
The results are shown here, truncated for readability:
INFO: lang name: ECMAScript
INFO: lang version: 1.8
INFO: engine version: 1.7 release 3 PRERELEASE
INFO: engine name: Mozilla Rhino
INFO: [js, rhino, JavaScript, javascript, ECMAScript, ecmascript]
The output shows that by default there's only one factory available, and its purpose is to
execute JavaScript (or, more formally, ECMAScript). This factory can be retrieved using
any of the names on the last line, but there's only one factory available, and it has nothing
to do with Groovy.
Fortunately, making a Groovy script engine factory available is easy. One of the features of
the
ScriptEngineManager
class is that it detects new factories using the same exten-
sion mechanism used for JAR files. In other words, all you have to do is to add the Groovy
libraries to your classpath via the groovy-all JAR. Once you do that, the same program pro-
duces the additional output shown here:
INFO: lang name: Groovy
INFO: lang version: 2.1.3
INFO: engine version: 2.0
INFO: engine name: Groovy Scripting Engine
INFO: [groovy, Groovy]
In this case the script engine reports that the Groovy language version is 2.1.3 and the en-
3
I did use the Groovy 2.1.5 compiler, but the script engine still reports 2.1.3. It doesn't affect the results, though.
In this particular API, even though a factory is now available, you don't need to use it to
acquire the script engine. Instead, the
ScriptEngineManager
class has a method to
retrieve the factory by supplying its name (either
groovy
or
Groovy
, as shown in the
previous output) in the form of a
String
. From the
ScriptEngine
I can then execute
