Release 8.x



Groovy 4 update

We have updated ScriptRunner for Jira Server/Data Center to Groovy 4!

Our primary motivator for this update is to provide support for JDK 17. Groovy 3 doesn't support JDK 17, and with Jira 9.5.0 and Confluence 8.0 being JDK 17 compatible, an upgrade to Groovy 4 is necessary.

So, apart from JDK 17 compatibility, what comes with this update and how will it benefit you? 

New features in Groovy 4

The following are the most significant new features that have been added in Groovy 4 :

Please have a look at the Groovy 4 Release Notes for a complete list of new features.

Breaking changes in Groovy 4

Groovy 4 contains a number of breaking changes. The ones which are the most significant, and likely to affect ScriptRunner users, are listed below. Please have a look at the Groovy 4 Release Notes for a complete list of breaking changes.

1) Changes to the resolution of properties with both a getter and isser returning different types

An isser is a method to retrieve boolean properties. Instead of the method name starting with get (as is common for accessor methods), it starts with is. See the JavaBean Properties tutorial for more information.

For properties that have a getter and an isser returning different types (for example, JiraAuthenticationContext#getLoggedInUser and JiraAuthenticationContext#isLoggedInUser) when accessing the property, instead of calling one of the methods (for example, jiraAuthenticationContext.loggedInUser), the getter is called in Groovy 3 but the isser is called in Groovy 4 - see GROOVY-10821. You don't need to worry about updating scripts with the loggedInUser property on JiraAuthenticationContext as we have included a patch (see more below).

ScriptRunner for Jira patch

For backward compatibility reasons, ScriptRunner ships with a patch to keep the old Groovy 3 behaviour for two conflicting Jira API properties commonly used in customer scripts:

  • The loggedInUser property on JiraAuthenticationContext 
  • The created property on Issue

We've included this patch as these properties will likely be heavily used in users' scripts. This means you do not need to change any code using these properties.

Solution for other properties

From Groovy 4 if you have custom classes, or are using external classes that implement conflicting isser and getter methods, and you are using the property syntax to get the getter value, you must re-write the logic to use the getter method directly.

For example, this class demonstrates conflicting isser and getter methods:

class GetterIsser {   String getSomething() { 'yes' }   boolean isSomething() { false } }   def myClass = new GetterIsser()   myClass.something // used to return 'yes', as of Groovy 4 will return false

From Groovy 4, this should be written as:

class GetterIsser {   String getSomething() { 'yes' }   boolean isSomething() { false } }   def myClass = new GetterIsser()   myClass.getSomething() // will return 'yes'
2) Legacy package removal

Groovy 3 provided duplicate versions of numerous classes (in old and new packages) to allow Groovy users to migrate towards the new JPMS compliant package names - see the section about it in Groovy 3 Release Notes for more details. Groovy 4 no longer provides the duplicate legacy classes.

For backwards compatibility reasons ScriptRunner still ships with deprecated version of groovy.util.XmlSlurper and groovy.xml.XmlParser. We recommend you don't use these legacy classes going forward and use their equivalents that can be found in groovy.xml package.

3) Changes related to how Groovy code accesses private fields from within closures

Groovy developers are currently attempting to improve how its code accesses private fields in certain scenarios, where such access is expected but problematic. For example, within closure definitions where subclasses or inner classes are involved (GROOVY-5438). You may notice breakages in Groovy 4 code in such scenarios until they fix this issue.

4) Change to intersect() default Groovy method

intersect() default Groovy method used to draw elements from the second argument passed to it, but now it draws elements from the first argument passed to it - see GROOVY-10275.

Deprecated SrSpecification class removed

Authors of Script Plugins may be used to writing tests which extend the deprecated com.onresolve.scriptrunner.canned.common.admin.SrSpecification class. This class has been removed. Authors of tests for their scripts should extend the spock.lang.Specification class directly. The Test Runner Built-in Script should still pick up tests as normal.

HAPI update

We've made a breaking change related to retrieving the customer request type. Find out more details in the HAPI Changelog

New Features

Key Summary Status

Bugs Fixed

Key Summary Status

On this page