Bitbucket Data Center 9.0 Early Access Program release

Followup on the Condition issue. The same exception appears when I want to use a condition on a web-resource.

It has been fixed and will be released in next EAP, thanks for raising.

1 Like

Thanks for raising this.

Context has been updated, it will be released in next EAP.

This is intended and documented in the webresource 7.0.0 upgrade guide:

com.atlassian.plugin.web.Condition can no longer be used on web-resources, use UrlReadingCondition instead. Condition will not be deleted, it will remain part of web fragments and can continue to be used with web-item, web-section, and web-panel.

For your other query regarding Condition and the use in CSE, we are still looking into it. Thank you for your patience.

1 Like

Can you implement both Condition and UrlReadingCondition? This should mean no exceptions are thrown.

I’ll look to get the documentation updated - to use conditions with CSE, both

  • com.atlassian.plugin.web.Condition
  • com.atlassian.webresource.spi.condition.UrlReadingCondition

must be used

Does this mean you will also add com.atlassian.applinks.api.ApplicationType and com.atlassian.applinks.spi.util.TypeAccessor ? I think we’lll need them to use MutatingApplicationLinkService

Yep. I tested locally with:

  • com.atlassian.applinks.spi.util.TypeAccessor
  • com.atlassian.applinks.api.ApplicationType

with the yet unreleased eap and I am able to access these classes & use methods from them in an external plugin

1 Like

Can the Bitbucket/platform team please test whether atlassian-pocketknife-dynamic-modules works with the EAPs?

We’re seeing modules register, but seemingly do nothing, and not appear in the UI. For example our web items are not showing up. If we move the module XML out of pocketknife things appear to work.

If we turn on debug logging there’s various warnings I assume from grey API restrictions:

2024-07-10 12:09:21 [ThreadPoolAsyncTaskExecutor::Thread 31] DEBUG c.a.s.i.plugin.OsgiSafeProxyProvider - Error creating OSGI safe proxy. Returning unproxied bean instead.
java.lang.IllegalArgumentException: com.atlassian.plugin.schema.descriptor.DescribedModuleDescriptorFactory referenced from a method is not visible from class loader
	at java.base/java.lang.reflect.Proxy$ProxyBuilder.ensureVisible(
	at java.base/java.lang.reflect.Proxy$ProxyBuilder.validateProxyInterfaces(
	at java.base/java.lang.reflect.Proxy$ProxyBuilder.<init>(
	at java.base/java.lang.reflect.Proxy.lambda$getProxyConstructor$1(
	at java.base/jdk.internal.loader.AbstractClassLoaderValue$Memoizer.get(
	at java.base/jdk.internal.loader.AbstractClassLoaderValue.computeIfAbsent(
	at java.base/java.lang.reflect.Proxy.getProxyConstructor(
	at java.base/java.lang.reflect.Proxy.newProxyInstance(
	at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(
	at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(
	at org.springframework.aop.framework.ProxyFactory.getProxy(
	at com.atlassian.stash.internal.plugin.OsgiSafeProxyProvider.createNewProxy(
	at com.atlassian.stash.internal.plugin.OsgiSafeProxyProvider.proxy(
	at com.atlassian.stash.internal.plugin.OsgiSafeHostContainer$1.apply(
	at com.atlassian.sal.core.component.DefaultComponentLocator.getComponentInternal(
	at com.atlassian.sal.api.component.ComponentLocator.getComponent(
	at com.atlassian.pocketknife.internal.lifecycle.modules.CombinedModuleDescriptorFactoryProvider.getHostModuleDescriptoryFactory(
	at com.atlassian.pocketknife.internal.lifecycle.modules.CombinedModuleDescriptorFactoryProvider.getModuleDescriptorFactory(

Can we please get confirmation that this library works on the EAPs? @vskalrud @TomRijnbeek

Hmmm this seems to happen because we’d put application="bitbucket" on our web-section modules, well we don’t need that so I’ve removed it.

The debug warnings about failing to create JDK Proxy instances still persist though.


As discussed some time ago, and following your suggestion, in order to retrieve the pull request settings for a repository, we have been using the classes

  • (and injecting with @ComponentImport)

We were finding these from com.atlassian.bitbucket.server:bitbucket-rest
but now that we’ve switched to bitbucket-rest-v2, we cannot resolve these imports.

Are these classes still avalailable in some other package?

1 Like


  1. Is it correct, that Bitbucket 9.0 only supports JDK 17 and no other major JDK version?
  2. What are the plans to support JDK 21 to run Bitbucket?

Thanks for raising this, the replacement classes can be found in




We’re going to change the return type in the next EAP to Map<RefChange, List<RefRestriction>> so it doesn’t have this problem. Thanks for highlighting it.


Is it correct, that Bitbucket 9.0 only supports JDK 17 and no other major JDK version?

Yes. Bitbucket 9.0 will only support Java 17 and will not support Java 21.

What are the plans to support JDK 21 to run Bitbucket?

I don’t know specifically when support will be added but it will definitely be supported in our first 9.x LTS (which is still several months away).


Thanks for raising. We’ve tested atlassian-pocketknife-dynamic-modules with eap10 and are able to load modules dynamically.

We’re going to investigate the debug logging, however it shouldn’t prevent pocketknife from working. Are you still facing any blockers from using pocketknife? Are you using the latest version 3.0.3?

Is there a flag or something to disable websudo in Bitbucket? SImilar to what you can do in Jira:[…]nistrator%20sessions (edited)

1 Like

You can disable websudo by adding feature.websudo=false to your file.


9.0.0-rc7 has now been released!

We’d like to announce the release of our first Bitbucket 9.0 release candidate, 9.0.0-rc7.

As you might guess from the change in terminology, we don’t anticipate any major changes between this release and the final Bitbucket 9.0 release. We’ve been running this release on Atlassian’s Bitbucket DC systems and it’s proven stable and performant. We also believe we’ve addressed all the API feedback gathered from this thread and other Atlassian Platform 7 threads.

In addition to the changes below, we’ve written some guidance on how to migrate your Bitbucket plugins to REST v2: Bitbucket RESTv2 migration for plugin developers. Hopefully, this helps accelerate your plugin migration.

You can download 9.0.0-rc7 with these links:

Changes in this release

Updates based on partner feedback:

  • Changed the return type of RefRestrictionService.match to Map<RefChange, List<RefRestriction>> so it doesn’t use a Guava type.
  • Allowed the use of Applinks spi classes such as and com.atlassian.applinks.spi.util.TypeAccessor
  • Fixed a bug preventing the Theme menu from showing

Improvements to Client-side Extensions:

  • Added fileChange context to the following file-content CSE extension points:
    • bitbucket.file-content.source.toolbar.primary
    • bitbucket.file-content.source.toolbar.secondary
    • bitbucket.file-content.diff-view.options
    • bitbucket.file-content.diff.toolbar.primary
    • bitbucket.file-content.diff.toolbar.secondary
  • The fileChange context contains information such as commitRange and path

The following packages have now been made public: