Confluence 8.8 release EAP available now

[scott.dudley]

Hi @mkemp,

@mkemp

If a plugin still uses Guava that’s okay, they’re compatible. Just be aware that if using lambda notation and compiling against a version of the interface that’s still using Guava then the Guava dependency needs to come from somewhere (either compile scope or OSGi package import) as the Java compiler will compile it using the Guava interface.

The deprecation notices where they make sense to have should be complete. What is probably better though is the upgrade guide

I really appreciate the clarification, as well as re-flagging the issue to the Confluence team–thanks so much!

You mention that if the plugin still uses Guava, then that’s okay. I assume you mean that’s because the Guava Supplier class extends java.util.function.Supplier, which is what the new <data> interface expects.

If that is the case, this will work fine in Confluence 9.0+, but I don’t see how to make the same code work in 8.0, with or without bundling Guava. Won’t the earlier version of the WRM expect my class to extend the Guava Supplier signature that’s compiled directly into the system bundle?

I agree with @rlander in that my currently cross-major-compatible app will have to be pried out of my cold, dead hands…resulting in this ask:

Since Atlassian is changing the signature of the interface required to implement the <data>, could Atlassian pretty please also consider changing the name of the element so that we can try to manage this?

For example:

<web-resource ...>
   <data class="class.based.on.old.guava.dependency" />
   <data2 class="class.based.on.new.javax.Supplier" />
</web-resource>

Old versions of the product will read <data> and ignore <data2>, new versions will do the opposite, and everyone is happy without classloader conflicts. This would also be really nice to do for any other module type whose signature is being changed in any way.