Preparing for Confluence 8.0 - EAP coming soon

Preparing for Confluence 8.0 - EAP coming soon

We’re excited to share our plans for the upcoming platform release for Confluence Server and Data Center.

Platform releases are an opportunity for us to lay the foundations for future Confluence 8.x releases, and will include some breaking changes and significant platform upgrades.

Predicted scope of breaking changes in 8.0

As development on Confluence 8.0 progresses we’ll be able to provide much more specific details of any breaking changes that could affect your apps. Our intention today is to give you a broad overview of the areas that we’re focusing on, especially those we expect there to be an impact to your apps.

As always, the Preparing for Confluence 8.0 page will be updated regularly with full details. We’ll do our best to include any breaking changes as early as possible, to give you enough time to schedule changes to your app before the official Confluence 8.0 release.

Some of the things we’ll be working on include:

  • Java 17 runtime support to ensure we can run on supported Java LTS releases for the lifetime of Confluence 8. We’ll also end support for Java 8 in Confluence 8.0.
  • Lucene API isolation, which will make it possible for us to upgrade Lucene in future, providing better search performance at scale, with less impact on your apps.
  • Removing direct access to Hibernate, which will allow us to upgrade Hibernate more frequently, without breaking your app, or requiring you to do significant testing and rework each time we upgrade. We’ll provide a migration guide with alternative methods you can use.
  • Removing the ability to use a dark feature to activate the TinyMCE 3-based editor (from Confluence 6.x) which will enable us to remove or replace a number of global variables exposed by the editor.
  • Remove the ability to upgrade from Confluence 5.x directly to 8.x, which will simplify the upgrade process. You’ll still be able to upgrade from 6.x directly.
  • Platform 6, which includes upgrades to many Atlassian and 3rd party components, and gives us the benefit of the most recent security and bug fixes.

These significant changes are necessary for us to provide a stable, secure, modern platform to build the next few years of Confluence releases on.

Test with Early Access Program (EAP) releases

Early Access Program (EAP) releases provide an opportunity to test your app with the upcoming platform release. We plan to release regular 8.x EAP milestones, in addition to the weekly 7.x EAP milestones. Get the latest milestones from the Early Access Program downloads page.

If you have questions or feedback for us, drop a comment below. You can also raise a feedback ticket.

Frequently asked questions

We know that platform releases have many unknowns. Here are some questions that we wanted to address with the information we currently have.

When will Confluence 8.0 be released?

We can’t provide an exact date at this stage, but we’re currently targeting late-2022. We’ll continue to release regular Confluence 7.x versions, including another LTS (7.19), while we work on 8.0.

Will there be breaking changes to APIs?

Yes, we expect there may be some breaking changes to the REST API or Java API. We aim to communicate these as early as possible.

Are there any restrictions to who can access to Confluence 8.0 EAP milestones?

No, the EAP is open to everyone.

Will there be additional resources to help us prepare?

Yes! The Preparing for Confluence 8.0 page is the source of truth for all resources. We’ll link to any additional materials, such as migration guides or Community posts for particular changes.

Here’s to the next stage of Confluence’s evolution,

The Confluence team


Hi @Wendy

I get errors when I try to compile the code, do I have to do something extra for this version?

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project restapi-extender: Compilation failure
[ERROR] /Users/r2d2/atlassian-workplace/restapi-extender_6.10/src/main/java/com/itlab/confluence/plugins/restextender/helper/[5,40] cannot access com.atlassian.confluence.license.DefaultLicenseService
[ERROR]   bad class file: /Users/r2d2/maven-repository/repository/com/atlassian/confluence/confluence/8.0.0-m011/confluence-8.0.0-m011.jar(com/atlassian/confluence/license/DefaultLicenseService.class)
[ERROR]     class file has wrong version 55.0, should be 52.0
[ERROR]     Please remove or make sure it appears in the correct subdirectory of the classpath.

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project restapi-extender: Compilation failure
[ERROR] /Users/r2d2/atlassian-workplace/restapi-extender_6.10/src/main/java/com/itlab/confluence/plugins/restextender/helper/[5,38] cannot access com.atlassian.confluence.pages.Page
[ERROR]   bad class file: /Users/r2d2/maven-repository/repository/com/atlassian/confluence/confluence/8.0.0-m011/confluence-8.0.0-m011.jar(com/atlassian/confluence/pages/Page.class)
[ERROR]     class file has wrong version 55.0, should be 52.0
[ERROR]     Please remove or make sure it appears in the correct subdirectory of the classpath.


Am I right in thinking that the new minimum JVM version is JDK 11, with runtime support for JDK 17?

Could this be added to the “Preparing for Confluence 8” page? It’s an important detail.


I confirm, after switching to JDK 11 everything works fine :slight_smile:


Thanks for raising this @adam.labus. I’ve passed your question on to our engineers to come back to you.

@Wendy cool :slight_smile: I have seen that a docker image atlassian/confluence-server:8.0.0-m011-jdk11 has already been published. Will there be a jdk17 image as well? That would be awesome :slight_smile: thanks

UPDATE: I have tested my app against this docker image and everything looks fine.
Except the PDF Export of a page seems to show my macro without any CSS styling.
It seems the whole PDF Export is done differently by Confluence 8 now.
How can I provide a print CSS for the PDF Export?

1 Like

Hi @Wendy,

Thanks for providing the updates. Is it possible to get your team to fix a problem with Bandana before rolling out this change?

We are using Bandana for certain types of storage. While we do not use Hibernate directly for persistence, we previously encountered performance-at-scale issues with certain native Bandana operations. These problems forced us to interface with the Hibernate Session object surrounding certain Bandana calls, using an interface that is now about to be removed.

The core problem is that, for every single fetch of data with BandanaManager#getValue, Confluence flushes Hibernate. During a flush, Confluence appears to be evaluating each previously-fetched object in the session to see if that object’s values have changed. This is O(n^2), so it breaks down when trying to load, say, 10,000 Bandana values. For example, even with a hot/fully-populated cache, we were still seeing 20+ ms load times for loading single values.

To solve the issue, we wrapped our calls to BandanaManager#getValue. We fetch the session from the to-be-removed PluginHibernateSessionFactory, call session.setFlushMode(FlushMode.NEVER), call Bandana’s getValue method, and then restore the previous flush mode.

There is a replacement EntityManagerProvider interface in Confluence 8.0, but as far as I can tell, the resulting interfaces do not seem to support the old FlushMode.NEVER. And even if they did, we would rather avoid having to mess with the moving target of the Hibernate-du-jour and calling internal APIs to fix a problem that was not really ours to begin with.

Can Bandana be fixed so that it does not try to flush everything for simple read operations? This would help us a lot and eliminate the need for any of these workarounds and extra interfaces.


1 Like

Hi @rlander, so sorry I missed mentioning that on the preparing for 8.0 page. It’s been added now.

The best place to see all the end of support announcements is on the End of support announcements for Confluence page.

1 Like

Hi @scott.dudley, I have passed your comment on to our engineers to come back to you.

1 Like

Hi @clouless I have passed your questions to our engineers to come back to you.

1 Like

I understand Hibernate, but please keep open an official way to access the SQL, though. Why?

  • Because ActiveObjects is extremely badly usable (The original developer was heroic, because the effort was huge, but always insufficient compared to the scope of the idea) and, notably, doesn’t have GROUP BY aggregations. Queries such as SELECT kind, COUNT(*) FROM ... GROUP BY kind are needed very frequently, as soon as we need to display the “most used” items or show statistics in the administration to suit our corporate customers, who themselves have reports to do with their own managers to justify the spendings. In other words, aggregations make a lot of money, and ActiveObjects doesn’t have them.
  • More globally, ActiveObjects escapes columns with a regex, which is the wrong tool because complex queries are mangled instead of escaped. It’s also the reason why AO never isolated us from which DB is used. So we have to use direct SQL access to get the data we need, and we write our queries 4 times (for each DBMS).
  • Lastly, when we want to migrate data from Bandana to ActiveObjects, the only way is to query the Bandana table directly, because Bandana doesn’t allow enumerating keys, even just keys starting with a given prefix.
1 Like

Hey @clouless,

@Wendy brought your request up with the development team.

At this time we’re not planning to release Java 17 containers for the Confluence 8.0 betas. We’re needing to work on optimisations for them, and they’re just not ready yet. We expect Confluence should run at this point, but not well. Basically your mileage may vary.

If you’d like to get ahead on the testing front, you can build the containers yourself. You can find the container code at Bitbucket

To make it work

  1. Clone the repository
  2. Edit the Dockerfile to change ARG BASE_IMAGE=adoptopenjdk/openjdk11 to ARG BASE_IMAGE=adoptopenjdk/openjdk17
  3. In your terminal, navigate to the directory you clone the repository into
  4. Then build the docker image with docker build --tag confluence-milestone --build-arg CONFLUENCE_VERSION=$CONFLUENCE_VERSION . where $CONFLUENCE_VERSION is the release of Confluence you want to build

After that, you can simply start the docker container using the confluence-milestone tag.

Hopefully this is of help :slight_smile:

James Ponting
Engineering Manager - Confluence Data Center


Hey @aragot,

Another follow up after @Wendy passed on your request.

Moving forward, we’ll be providing a new interface via JPA, as opposed to the previous Hibernate interfaces. If you pull down the EAP, you should be able to execute native SQL queries with entityManagerProvider.getEntityManager().createNativeQuery("select * from table");

Can you let us know if that works for you? :slight_smile:

James Ponting
Engineering Manager - Confluence Data Center


Great, yes, using createNativeQuery() is awesome! It solves my question. Thank you.


@jponting thanks :slight_smile: It will work for me now, but I am hoping you will provide the jdk17 images soon :slight_smile:

What about my print CSS finding in PDF export? Can you help me with this as well?
When exporting a page no css for my macro is used to style the content.
The same app works on a previous Confluence version with valid print css in PDFs.


Hey @clouless,

We’re in the process of creating the containers with Java 17 support. Not sure exactly when they’ll be available, but when the deployments team is happy with them, we’ll set them free.

I’m not aware of any changes to our PDF export process in Confluence 8, so I am unsure of what you’re seeing. I understand that CSS isn’t being passed as you expected, can I ask if it’s passing as expected with Java 11?

James Ponting
Engineering Manager - Confluence Data Center

@jponting regarding PDF my e2e tests shows me that the download URL changed

expected substring: "/download/temp/pdfexport-"
Received string:    "/download/export/pdfexport-20220615-150622-1344-5/....

UPDATE: :white_check_mark: Everything works with jdk11 (jdk17 not tested yet)

:man_facepalming: sorry for the noise. The baseUrl was not correct on my testinstance, that seems to have made loading of print CSS impossible during PDF export.
I setup a fresh instance and now everything works.
Thanks a lot for the quick response, and sorry for posting stuff before my second coffee …


Lol, no worries at all. Glad you got it sorted :slight_smile:

1 Like

Hey @scott.dudley,

Apologies for the delay in getting back to you. The person I wanted to talk about this with has been hard to nail down.

I don’t have a great answer for you immediately, and I’m unsure as to the effort required to fix this one, so no commitment from us yet. The use of entityManagerProvider.getEntityManager().createNativeQuery("select * from table"); as I suggested with @aragot should allow you to access the table directly, and I understand that you can access it in a read only transaction, which should avoid the flush behaviour you’re seeing. This should achieve a similar outcome to the process you’re using now, even if it’s still a workaround.

With the coming improvements to Hibernate, we may see some improvement in the default behaviour, and hopefully we can improve it directly in the future.

James Ponting
Engineering Manager - Confluence Data Center

1 Like

Hi @jponting,

Thanks for getting back to me, as well as for doing all that research!

While I guess this workaround could work, it feels akin to trying to reprogram your Tesla with a socket wrench. I want the ORM from Hibernate, I want the entity caching, I want the existing management of the entity cache that is already configurable by the admin, I want the independence from the Bandana table format, I want the Bandana XML serialization/deserialization, and I don’t want to have to worry if your Bandana write caching is (or ever becomes) not write-through.

To use the entity manager directly, we have to throw all of that out and replace one call to “bandanaManager.get(X)” with a few hundred lines of code, which becomes fragile if Atlassian ever changes anything with Bandana. By that point, it effectively turns into a forced migration to ActiveObjects, since it would be as much work, but at least AO is a supported interface.

I understand that fixing this could be complicated. Absent that, are you possibly able to determine if you are still intending to enable this flush behavior in the version of Hibernate that you are planning to ship? If the Hibernate upgrade also somehow mitigates this, I guess that is fine…but could you tell us when the final 8.0-targeted version of Hibernate is going to be bundled (or if it is already)?

For reference, here’s a screenshot I took from one of our internal tracking issues showing where all the time was getting eaten up during Bandana fetches (testing vs. Confluence 6.13.7).


1 Like