Jira Service Desk is deprecating com.atlassian.fugue in 3.15



Hi everyone,

Today we published a deprecation notice for the use of com.atlassian.fugue in Jira Service Desk 3.15.

I strongly recommend you read the full deprecation notice here. In summary:

We’ll be deprecating the use of com.atlassian.fugue in Jira Service Desk 3.15.
In Jira Service Desk 4.0, we’ll be updating our APIs to use Core Java Data types and Exceptions.
You’ll need to update any scripts, integrations or apps that make requests to endpoints returning com.atlassian.fugue with the release of Jira’s 8.0 Early Access Program (EAP).
In accordance with the Java API Policy for Jira, support for com.atlassian.fugue will continue to exist and work in the following minor release, but will be removed in the next major release.

Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team

Let's talk about Jira 8.0

Hi @lgoodhewcook,

this will obviously have a serious impact on both app vendors and customers who created their own scripts (e.g. Groovy scripts in ScriptRunner or JMWE).

While customers will “simply” need to update their scripts when they upgrade to JSD 4.0, how about app vendors? We obviously don’t want to have to “branch out” development for Jira 8 + JSD 4.0 and maintain two lines of code (we all know migration to Jira 8 will be very gradual). Do you have an approach to recommend for maintaining dual compatibility with both JSD 3.x and 4.0 in a single app version?


Hi @david2 ,

Yes this will have an impact on vendors. Luckily it will only affect the consumers of the Java API so if they’re using REST APIs for their scripts or add-ons then they have nothing to worry about.

For consumers of the Java API that want to simultaneously support both versions of the API I would suggest a bridge layer that would decide what version of the API to use and converting it to your own internal preference. I have anecdotal evidence that quite a few vendors already have similar and we even do something like that for Portfolio for Jira.

So abstracting calls to the JSD API through your own wrapper

       Your code
      JSD Bridge
     |            |
 JSD 3.x       JSD 4.x

The choice of whether you convert the exceptions to Either<AnError, T> like it used to be or convert the Eithers to Exceptions is entirely up to the vendor and how they want to handle things.

Those might look something like

try {
	ServiceDeskComment serviceDeskComment = serviceDeskCommentService.getServiceDeskCommentById(user, commentId);
} catch (ServiceDeskServiceException e) {
    return Either.left(new AnError(ErrorMessage.builder().message(e.getMessage()).build(), HttpStatusCode.INTERNAL_SERVER_ERROR));


either.fold(err -> {
    throw new ServerException(err.getMessage());
}, Function.identity());

Both of which I’d put in some kind of helper to help keep the duplication down.

Hope that helps

Lachlan Goodhew-Cook
Senior Developer, Jira Service Desk Team


Hi @lgoodhewcook,
thanks for the detailed answer.
So basically we need to develop three new JAR libraries - the JSD bridge that will load either the 3.x or the 4.x implementation based on the JSD version (which I assume we read from the UPM), a JSD 3.x implementation that depends (in the Maven sense) on the JSD 3.x API, and a JSD 4.x implementation that depends on the JSD 4.x API, correct? That’s a lot of work though - don’t you think that’s something Atlassian should be providing, like the user compatibility library Atlassian provided with the Jira 7 release?


Hey @david2,

Your understanding of what needs to be done with the libraries is spot on. You’ll only need to implement interfaces for the functions you want to consume. We appreciate the effort on your part to set this up and are here to offer guidance through the process.

Atlassian has no plans at the moment to provide a library supporting development for multiple versions of Jira Service Desk at once.

Lachlan Goodhew-Cook
Senior Developer,
Jira Service Desk Team