Install a Scripting runtime Engine (Nashorn, Groovy, Graal)

Owned by Andy Brook [Plugin People]
Last updated: Jan 05, 2024 by Ryan Clifton
6 min read

 since JEMH 2.5.3 for Jira 7.7.x

Summary

Within JEMH you are able to install and use additional scripting languages. This pages covers the relevant files and versions that are needed to install Nashorn, Groovy and Graal when using Java 8,11 or 17. Note: how these different languages are installed will depend on the Java version that is in use.

Installation of additional languages

System Administrators can make additional scripting languages available by adding their respective JSR-223 compliant JAR file into <jira_installation_directory>/lib folder or adding directly into the JDK that is Jira/JEMH is using. Once done, the Extensions screen of JEMH should show the language as being installed:

Scripting Languages

Below are three Scripting Languages that we have tested and have created guides for.

Nashorn

Within Java 8/Java 11 they come with Nashorn, an engine supporting ECMAScript-262 5.1 standard. Within Java 17 this is not included by default, which means that to use Nashorn you will need to add the relevant files to the Java that is used by Jira or by adding the file to Jira-install/lib

For more info about installing Nashorn within Java 17 see: Installing Nashorn (ECMAScript) Script Engine

Groovy

By default Groovy is not included within any Java and currently cannot be added directly into the JDK. Due to this it means that you would need to download and place the relevant files within jira-install/lib in order to use Groovy within JEMH/Jira.

For more info about installing Groovy see: Installing Groovy Script Engine

Note: If you have ScriptRunner installed, then you will not need to included the files within jira-install/lib as JEMH is able to utilise the Groovy version that is bundled within the ScriptRunner application.

Graal

By default Groovy is not included within any Java version. Due to this it means that you would need to either install Graal directly into Java or by adding the relevant files into jira-install/lib

For more info about installing Graal see: Installing Graal Script Engine

 

Methods of installing additional Scripting Languages

There are two possible methods of installing additional Scripting Languages.

  1. Installing the files directly into the JDK - This method is to modify the JDK so that it includes the relevant files for the scripting Languages. Recommended method

    1. This method only works for Nashorn and Graal.

    2. Note: Not all Jar files contain a module-info.class file, which is required to install the modules within Java. For more info about how to resolve this see the Adding module-info.class within the Jar file section below.

  2. Installing the files into Jira-Install/lib - This method is to add the specific file to the lib folder of a particular Jira install. With this method it means that you do not need to modify the Java version that is used. This is done by placing the relevant Scripting files within Jira-install/lib.

    1. This method will work for Nashorn, Graal and Groovy.

Adding module-info.class within the Jar file

When adding the files directly into Java you will need to ensure that they contain a Module-info.class file as this is used to identify that the jar file can be used as a Java module. If the jar file does not contain the Module-info.class file then you would need to create this file by using the following commands. This will then allow the jar files to be used as a module within the Java Runtime Environment.

Note: Most of the files mentioned in the above pages do contain this Module-info.class file, which means that the below steps may not be necessary.

Creating module-info.java

The following terminal command will generate a module-info.java file that contains the relevant information about the jar file.

jdeps --generate-module-info out <jar_file_path>

Compile module-info.java to create module-info.class

This will compile the module-info.java file into a module-info.class which can then be used to identify the jar file as a module. Note: <module name> is identified when the above jdeps command has been run.

javac --patch-module <module_name>=<jar_file_path> out/module-info.java

Add the missing module-info.class into the jar file.

This will place the created module-info.class file into the jar file.

jar uf <jar_file_location> module-info.class

 

Known Issues

Compatibility with ScriptRunner

So, if ScriptRunner is to be used, the above method will cause ScriptRunner to not start as ScriptRunner bundles a Groovy runtime within it.  After removing the manually added JAR (if done), JEMH will happily detect ScriptRunner and use the available runtime it contains.  Again, the JEMH Extensions screen shows what runtimes have been found, from what source, here you can see ScriptRunner is listed as the source for Groovy (notice the Language version difference between the 3.0 alpha above).

Compatibility with JavaAgent:

When using a JavaAgent you may have to specify some JVM arguments within the setenv.sh file and when these arguments are incorrect or missing then it can cause issues with the JEMH functionality. Below are some known issues we have found when the JVM arguments have been defined incorrectly.

Errors when using Scripts

When attempting to use JEMH scripting features there may be an exception that identifies that Nashorn scripting could not be found and as a result the scripting features will not work and will show the exception. When adding the JVM arguments for the JavaAgent you may use -Datlassian.org.osgi.framework.bootdelegation which is not supported by Jira. You should use -Datlassian.org.osgi.framework.bootdelegation.extra instead as this will retain the scripting functionality and will also successfully incorporate the JavaAgent within Jira. More information about this can be found on the following Atlassian page: https://confluence.atlassian.com/jirakb/adding-classes-to-osgi-boot-class-loader-bootdelegation-973483231.html

Below is the exception that is shown when -Datlassian.org.osgi.framework.bootdelegation is used:

Errors when making Profile Configuration changes

When attempting to save, export or delete your Profile you may encounter an exception which will stop these features from working. This is due to com.sun.xml.bind being missing within the JavaAgent JVM arguments and adding com.sun.xml.bind to the JavaAgent argurments will solve this issue will return the Profile configuration features.

Below is the exception that is shown when com.sun.xml.bind is not defined:

Example Working JavaAgent JVM arguments

Below is a working example JVM_SUPPORT_APPD_RECOMMENDED_ARGS argument that is used when configuring AppDynamics JavaAgent for Jira.

Jira does not start with Java 17

When using Jira 9.5.0 to 9.10.2 with Java 17 you may encounter an error when attempting to start and access Jira:

This appears to have been resolved within Jira 9.11.0+

Solution

The solution to this is to add some arguments within the setenv.sh file as these arguments will allow Jira to startup when using Java 17. See the following Atlassian page for more information about the required arguments: https://confluence.atlassian.com/jiracore/java-17-runtime-opens-and-exports-arguments-1188413810.html

Below are the relevant arguments that needs to be added to the setenv.sh file: