RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It’s not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Project summary
We’re upgrading Spring, Jakarta, and any other necessary dependencies to the latest stable version in all Data Center products: Jira Software 11, Jira Service Management 11, Confluence 10, Bitbucket 10, Bamboo 11, and a Crowd version to be released by the end of FY25.
Problem
Open Source Software (OSS) support for Spring 5.3.x, currently used in our Data Center products, has ended. To maintain high security standards, we’re updating to the supported 6.x line. Spring 6 is no longer compatible with the currently used Jakarta 8, requiring us to update the Jakarta version as well. This also means updating all the other libraries in our products that depend on Spring and Jakarta.
With this upgrade, we’re aiming to mitigate security risks by keeping dependencies supported and up to date. The update to Jakarta 10 represents a major shift in the Java EE world due to the namespace change from javax to jakarta. We see that the industry slowly focuses on the newer versions. We need to think about supportability in a 2+ years window. This update doesn’t just affect the libraries we’re working on now—by updating to the latest Jakarta 10, we’re also making it easier to update other dependencies in the future.
Solution
Spring
The Spring Framework provides dependency injection capabilities for apps and, together with the OSGi integration, it allows to share beans between them. As such, it’s one of the key elements of the Atlassian Plugin Framework.
We’ll upgrade to the latest Spring 6.2.x. We don’t plan to make any changes to the way Spring integrates with the Plugin Framework. However, some Spring concepts and behaviors have changed between versions. For a comprehensive description of changes, follow the official documentation:
- Spring Framework 6.0 Release Notes
- Spring Framework 6.1 Release Notes
- Spring Framework 6.2 Release Notes
Jakarta
Jakarta is actually a set of APIs related to each other. We aim to update to Jakarta EE Platform 10, specifically:
- Jakarta Servlet 6.0
- Jakarta RESTful Web Services 3.1
- Jakarta Dependency Injection 2.0
- Jakarta Annotations 2.1
- Jakarta Activation 2.1
- Jakarta Mail 2.1
- Jakarta XML Binding 4.0
- Jakarta Bean Validation 3.0
We won’t be making any changes to the Atlassian API unless they’re necessary because of the updates to the Jakarta API. There are also several API changes in Jakarta that may impact apps.
The plan assumes a replacement of the libraries. For example, as the Jakarta API changed the namespace, OSGi will export jakarta.* packages instead of javax.* for the APIs mentioned above.
Asks
While we’re happy to get any feedback on this RFC, we’re particularly hoping to get insights on:
- Anything you’d like to see to make the migration easier.
- Any hard blockers to migration you find.
