Improved security and usability: 2025 Data Center product updates

Announcements
, ,
1

Hello, Atlassian Developer Community!

Throughout 2025, we’ll be bringing changes to all of our Data Center products in their next major version:

  • 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.

These releases will include upgrades that provide a more secure experience, while enhancing the overall quality of our technical stack.

What’s changing?

Here’s an overview of the planned changes:

  • Upgrade to Spring 6 and migration to Jakarta 10—we’re upgrading the Spring version used in all products to Spring 6 due to the end of open-source support for Spring 5. This Spring version will no longer support Java EE(javax) which in turn will require us to upgrade to Jakarta EE 10. These changes will allow us to continue providing you with security fixes.
  • Upgrade to jQuery 3 —while Confluence and Bitbucket have already migrated to jQuery 3, we’re now aligning on jQuery versions across all products. This means a significant jQuery version uplift for products containing older versions of jQuery. Our current plan is to upgrade to jQuery 3, however we’re closely monitoring the potential of a final jQuery 4 release. This upgrade will make developing cross-product apps easier.
  • Removal of deprecated components from AUI 10—we’re removing components displaying accessibility issues: Toolbar 1 and Dropdown 1.
  • Upgrade of internal dependencies in AUI 10—we’re upgrading AUI 10’s internal dependencies to better support jQuery 3 and proactively address security issues.
  • End of support for the original theme—with the new light and dark themes that brought accessibility and usability improvements, we’re removing the original theme from all products.
  • Removal of the LESS transformer—we’re removing the ability to transform LESS to CSS at runtime, requiring LESS to be transpiled into CSS at compile time. We’ll provide CSS variables as a replacement for Look and FeelLESS variables.
  • Removal of Trusted apps—we’re removing Trusted apps to reduce the number of insecure entry points into the products. We’ve replaced this way of exchanging information between Atlassian products with more secure solutions that follow industry best practices, like the OAuth 2.0 protocol.
  • Basic authentication disabled by default—we’re disabling authentication with basic authentication by default. This is a first step towards the removal of basic authentication altogether as we develop and mature alternatives to support the remaining few use cases.

Each Data Center product may deliver additional improvements on top of these upgrades. We’ll communicate more details in future announcements and release notes.

How will these changes impact apps?

Your apps will need to be compatible with the new versions of Spring, Jakarta (and any dependencies we’ll have to upgrade to complete the migration to Jakarta), as well as jQuery 3. If your app utilizes Trusted apps, basic authentication, or runtime LESS transformation, you’ll need to migrate to available alternatives. We’ll communicate these in the future when we have more details to share.

We’re aware that these changes will require significant effort from you to adopt. However, we strongly believe those improvements make the Atlassian ecosystem more reliable and secure.

For those planning to attend Atlas Camp, we’ll be there to answer your questions and guide you through the process in person. We’ll also arrange for office hours or webinars early next year to support those of you who can’t attend.

What’s next?

You can expect announcements about the timing of the upcoming EAP releases of Data Center products containing these changes. We want to give you enough time to prepare and test your apps.

We’ll also publish the first Request for Comments (RFCs) for these updates very soon. We’ll update this Community post with the links.

Let us know what you think

We want to hear your feedback and ideas. Leave your comments under this post.

11 Likes
2

Thanks for the early warning.

Looking at the timeline and end-of-life of current product versions, I see an overlap of platform 6, platform 7, and this announcement (“platform 8”?):

  • Platform 6 versions:
    • Jira 9.17 (EOL date: 26 June 2026)
    • Confluence 8.9 (EOL date: 2 Apr 2026)
    • Bitbucket 8.19 (EOL date: 12 March 2026)
    • Bamboo 9.6 (EOL date: 14 Mar 2026)
  • Platform 7 versions:
    • Till 2027
  • This announcement (“platform 8”?):
    • For product-versions released in 2025

So, for some part of 2025 and some part of 2026 all 3 platforms are supported. So, we app vendors should also support all 3 platforms in our apps during that period, I guess. Correct?

Any chance to postpone this until platform 6 is end-of-life, so that we only have to support 2 platforms simultaneously?

6 Likes
3

Thank you for the early notice!

Our internal teams are kicking off our platform 8 investigation next week, so this is excellent timing.

The changes for platform 8 appear relatively straightforward on first inspection, albeit a bit tedious to implement. I also have a concern that some of our third party libraries may have hidden dependencies on javax packages, we’ll check that out.

For us the biggest help would be publishing a list of all impacted packages at the earliest opportunity. With ScriptRunner customer scripts are likely to be using some of the impacted packages, the earlier we know what is impacted the earlier we can proactively warn our mutual customers.

Unfortunately these changes do not appear to be backwards compatible, so as @AndreasEbert notes we will be maintaining 3 branches of code til 2026 :cry:

I appreciate that this is the announcement of breaking changes for the platform, as vendors we also need to know as soon as possible if any additional breaking changes are being introduced by the individual product teams.

So far we are aware of the Lucene deprecation impacting Jira, is there anything else we need to factor in to our planning?

Another key piece of information would be an indication of which product will ship a platform 8 EAP first, will it be Confluence again? This information will help us adjust our internal roadmaps and allocate resources appropriately to begin work immediately when an EAP arrives.

Thank you again for the early notice!

Cheers,

Reece

9 Likes
4

Hi Malathi,

thanks for the heads up - one question we have is in regards to the removal of the trusted apps functionality. We are not sure if this also has some implications to application links in general? We are still using an application link to enable OAuth1a login (delegated), so we were wondering if this will also be impacted by this announcement?

Thanks!
Tobias

5 Likes
5

The rest of the questions, we’ll need to get back to y’all, but I can answer:

Ah sorry, I had intended to post everything breaking we know of so far on the product UI side too for exactly this reason. The only others are 1) Removal of <client-resources (use <web-resources instead. 2) Replacing Client Web Fragments in Bitbucket with Client-Side Extensions, all existing CWF locations will gain CSE.

They should be relatively straight forward to migrate so these will likely land after the other changes.

5 Likes
6

Thanks for the feedback, @AndreasEbert . Unfortunately, we can’t wait until the end of life of Platform 6 due to the support timelines for Spring/Jakarta. We need to upgrade to the latest versions as soon as possible to maintain our security standards.

2 Likes
7

Thanks for the feedback, @rlander . We hear you and agree that these are valid concerns. We’ll aim to share a list of changes as soon as we have more clarity. In the meantime, we plan to post probable breaking changes on DAC as we identify them instead of waiting for a finalized list.

Regarding the EAP and product sequencing, we haven’t finalized anything yet but will update you once we do. It’s great to hear your team is already exploring this. We’re happy to collaborate with the community to make managing the three branches more manageable and less painful!

3 Likes
8

Hi @tobias.viehweger! Unless your Application Links use Trusted Apps for authentication, they should continue to work as normal. You can check whether your Application Link will break by checking if it’s status is set to “deprecated”. Normal OAuth 1 Application Links won’t see any change in functionality, and for the majority of use cases you can safely migrate Application Links from Trusted Apps to OAuth if you’re still using the deprecated links.

3 Likes
9

Are there any reasons you are able to share why it wasn’t done in platform 7?

1 Like
10

If you’re going to make front-end changes, can we please have a clear example of the canonical/recommended way to add JS to the front-end? As in, should we use require(), which require() are allowed, should we use React, etc. ?

11

Maybe I misunderstand what you’re saying? The changes we’re making shouldn’t affect the following existing/standing recommendations:

  • Component system: Atlaskit is preferred, AUI is supported
  • Module system: Use require(); AMD is preferred, UMD is supported. Avoid using global variables (not right now, but we will be defining more AMD modules to allow migration). If you’re using a bundler, you can use ESM syntax which is preferred
    • Don’t forget to declare the web-resource dependency too!
  • Extending existing pages: CSE is preferred, Web Fragments are supported
  • Creating new pages: CSE is preferred, vanilla servlets are supported
  • Web-resource definitions: Generating them atlassian-webresource-webpack-plugin - npm is preferred, writing them manually is supported
  • Getting JS/CSS/etc onto an existing page: adding to a web-resource context is supported, requiring your own resources via a web panel or web item etc is preferred. Avoid generic contexts like atl.general and atl.admin
  • Frameworks: React is preferred

If anything stops you (we know it’s not always possible) from taking the preferred routes I’d love to have a ticket, it helps us prioritise which problems and extension points.

2 Likes
12

Hi @lexek-92 , we considered including Spring and Jakarta updates in Platform 7 but decided not to for a few reasons:

  1. Platform 7 complexity: Platform 7 already had a lot of work, and adding more to the scope would have placed a heavy burden on both Marketplace partners and Atlassian developers.
  2. LTS release plans: Many customers plan their updates around the LTS schedule with specific downtime windows. To ensure we could meet the LTS timeline and avoid disruptions, we chose not to include these updates, as the overall workload would have made it difficult to deliver on time.
1 Like
13

Hi mkemp,

For all of your answers, there exist no public example of implementation, a lot of libraries are supposed to be open-source but searching on BitBucket doesn’t yield any result, and we haven’t succeeded to make large parts of it work (such as the live-reload), and we have put the work in (6 full-stack developers and 2 front-end developers), so I’m quite confident to say no-one in the community has a fully-functioning stack. Let’s review:

  • Component system: Atlaskit is preferred, AUI is supported → React isn’t available in current LTS versions of Confluence / Jira, and once React is in both versions of LTS, it will be a different version of React and it will be impossible to maintain the same code for React 16 and React 19. (We’ll ship in our own version of React as a remedy).
  • Use require() → Yes, that’s easy.
  • Avoid using global variables → Even in JIRA, major functions such as “JIRA.ViewIssueTabs.onTabReady” aren’t documented in AMD/aren’t available in AMD/we have to rely on guesswork.
  • atlassian-webresource-webpack-plugin - npm is preferred → Atlassian WRM (the webpack/npm plugin) doesn’t fully work. Despite having spend a month on it last year, then having hired a front-end consultant to work on it for a month as well: Either it wasn’t compatible with Webpack 5, or it’s Jira-but-not-Confluence, or we are missing a single variable that makes that nothing really works about it. It may seem simple for you, but it’s not — Can we have an example sandbox project that proves that it works in Confluence?

All of the rest is due to Atlassian WRM not working, and can be solved by providing a sample project showing us how it’s done.

  • Web-resource definitions: Generating them atlassian-webresource-webpack-plugin - npm is preferred → Atlassian WRM doesn’t work,
  • Extending existing pages: CSE is preferred → There is no public documentation about it and I’ve asked the community and they say CSE are Bitbucket-only. Atlassian people always send the link to the global explanation of CSE, which don’t explain how to set it up for example for Confluence and don’t contain public examples of a working CSE working in Confluence and Jira beyond BitBucket — and any further click redirects to the server-fe repository on Bitbucket, which is even more global. I’m suspecting you’re browsing your documentation logged-in with Atlassian credentials, and don’t realize the redirections we have,
  • Creating new pages: CSE is preferred → Again, lacking public documentation.
  • Getting JS/CSS/etc onto an existing page: requiring your own resources via a web panel or web item etc is preferred → PageBuilderService doesn’t work, we still have to rely on WebResourceManager.
  • Frameworks: React is preferred → Can’t, until Atlassian WRM works.

It may seem a lot of work, but I assure you my question is simple: Can we see a sample plugin, which contains Atlassian WRM, and which works in Confluence?

I’m very confident that poor architecture practices are spreading in the ecosystem because of the lack of available information. Driving adoption of excellent front-end techniques will impact your customer’s frontend tomorrow. We’re really keen to adopt Atlassian WRM, React, design tokens, CSE and Atlassian’s other guidelines for the sake of the performance of our mutual customers. A major factor in driving adoption is providing a sample plugin that proves that the suggested frameworks are ready for external usage.

Best regards

3 Likes
14

Yes, the documentation is lacking, but I’m pretty sure there’s a public example for everything. Unfortunately, they’re not easy to find.

I’ll quickly respond, but if you need to reply again, but so we don’t go too far off-topic, please instead create another CDAC thread or create Jira issues. Most platform components have their own issue tracker, if not, SPFE is fine. If it’s a product-specific issue, please create a jira.atlassian.com ticket

It doesn’t sound like any of these has to do with the changes in the upcoming major versions of our products? With the exception of CSE, but it doesn’t sound like you have problems specifically with respect to moving from Client Web Fragments to Client-Side Extensions?

Jira: https://developer.atlassian.com/server/jira/platform/jira-frontend-api/#code-sharing
Confluence: com.atlassian.confluence.plugins.confluence-super-batch:react-dom (although I don’t think it’s documented anywhere)
Bitbucket doesn’t expose a version as API

I would like to have a single web-resource for all products of the same major version in the future, first we have to do the work to get on to the same version. For now, perfectly fine to bundle your own version of React for products that don’t expose it or are on too old a version.

Yes, sorry that’s what I meant by we still have work to do. Jira will be defining and documenting their API here: https://developer.atlassian.com/server/jira/platform/jira-frontend-api/#jira-api-modules (pretty baren ATM). AUI does offer the module names in the documentation when they exist, e.g. Banners - AUI Documentation

It should be product independant, it sounds like you might have other issues? AUI uses Webpack 5 and is open source; it’s quite a complicated setup but it doesn’t cover hot-reloading.

We currently only have CSE extension points in Bitbucket, but it’s possible to use the page bootstrapper in any product and it’s possible to define your own extension points on your own UI in any product too.

All our DC UI Platform documentation is public AFAIK, I personally make a very strict point of it. Please give feedback when on developer.atlassian.com pages and we can action it, or in the issue tracker linked from the repository.

It’s both documented here and we have examples in the CSE repository.

Please create a ticket for the specific page where you’re having problem, ideally with a minimal reproduction repository, it should be working. Although if you’re not having any problems using WebResourceManager, that’s fine because it’s not going anywhere.

Definitely, we’re we want to be, we’re honestly still figuring out things ourselves. We still haven’t even finished unblocking all the modern practices and tech stack yet.

Absolutely and I love that you were thinking of how to reduce bundle size by sharing the same version of React. We (both Atlassian and vendors) can’t solve everything at once, these RFCs are one step at a time.

A common problem we had internally too. This bootstrap project is still relevant even if a little dated. We’ve instead been focusing on this via Atlas FE which will add a modern FE setup to any existing plugin.

Finally, while we don’t expect it, we do take contributions and we really appreciate them when they do come. Most DC Platform repositories live here with the notable exception of fe-server.

2 Likes
15

@mkemp Please make sure you don’t ‘drop’ any of the existing Client Web Fragment locations on the way, as Atlassian did with bitbucket.pull-request.nav which never got fixed!

IMO CWF to CSE extension warrants a separate RFC for Bitbucket DC. Can you please compile a list with existing non-CSE extension points and the equivalent post migration, something like the BBDC 7 announcement a while back.

3 Likes
16

Thanks @UlrichKuhnhardtIzym1, I’ll raise all three points with the Bitbucket DC team.