Thanks for your ongoing interest in this issue.
To find a comprehensive update on all things Java please see https://community.atlassian.com/t5/Agile-articles/Java-11-OpenJDK-support-update-for-Server-and-Data-Center/ba-p/967836

Loosely speaking, OpenJDK is source, and AdoptOpenJDK is a particular configuration of build tools and build settings applied to the source to create a set of distributable binaries.

Anybody can compile OpenJDK source. You could do it yourself. Linux distributions such as Fedora, CentOS, RHEL, Ubuntu, and so on compile it, and distribute it themselves in their native format. One key difference between AdoptOpenJDK and the Linux distro builds tends to be the choice of runtime libraries. I haven't reviewed them all - but let us just say that OpenSSL is one of them. With AdoptOpenJDK, it likely embeds OpenSSL as part of the build process, and AdoptOpenJDK is distributed with this embedded version of OpenSSL. This has the benefit of making AdoptOpenJDK more portable, in that the same binaries will work on more Linux distributions "out of box", but it also makes AdoptOpenJDK fatter, and less capable of being patched. In the case of the RHEL build of OpenJDK, it may dynamically link to all of these libraries, and they can independently update "java-1.8-openjdk" separately from "openssl".

A key difference is that the build process can define the "minimum runtime requirements". As a particular example that affected me more recently - is that we still have some RHEL 5 systems. Oracle JDK up until very recently worked fine on RHEL 5 systems. AdoptOpenJDK does not work on RHEL 5 systems, because it presumes a particular minimum runtime that is later than RHEL 5. In the case of a Linux distro build of OpenJDK, they will ensure that the OpenJDK build targets the runtime that is available for that Linux distro. The AdoptOpenJDK has a generic minimum runtime requirement which may not match requirements of where you wish to deploy OpenJDK.

An interesting example here that goes beyond just "minimum runtime requirement versions", is alternative processors such as ARM. OpenJDK as built for RHEL 7.6 with aarch64 target by Red Hat, may work fine with Confluence on an ARM-based server. But, AdoptOpenJDK doesn't produce builds for ARM.

OpenJDK comes with an extensive regression test suite that proves that a resulting build complies with "Java". As long as it passes, there is no reason why a favourite builder such as AdoptOpenJDK should be chosen as the only supported platform.

Atlassian recently provided some clarification that they will embed AdoptOpenJDK, test with AdoptOpenJDK, and expect that any problems reported can be reproduced on AdoptOpenJDK, but that customers can use OpenJDK from another builder and they will still receive support. It would be useful for this clarification to be included in the "Supported Platforms" section.

We could use AdoptOpenJDK, but we don't want to. There are benefits to using OpenJDK as built by your Linux distro, and we intend to take advantage of these benefits. If there is ever a time where the Linux distro of OpenJDK does not match AdoptOpenJDK, then this is a serious problem, and one of:

1. Confluence is relying on something OUTSIDE the Java specification. This is the same problem that resulted in a dependency upon Oracle JDK in the first place. This is bad, and should be eliminated by Atlassian. This falls under the category of "undefined behaviour". Nobody should choose to rely on "undefined behaviour", and Atlassian should be interested in squashing any cases of this.
2. AdoptOpenJDK or OpenJDK or the Linux distro of OpenJDK is not properly implementing the Java specification. In these cases, the issue should be raised to the right people for correction, and a regression test should be introduced to ensure it never happens again.

Is there any difference between OpenJDK and AdoptOpenJDK?

According to AdoptOpenJDK website:

"AdoptOpenJDK provides prebuilt OpenJDK binaries from a fully open source set of build scripts and infrastructure."

So they sound like one and the same

+1

Support for OpenJDK as in Linux distros is what can be considered as proper Solution to this ticket.

Vlad Mencl, REANNZ

We at CIRA agree with Mark as well. OpenJDK is expected.

We at Generali agree with Mark Mielke's point of view – OpenJDK (not only AdoptOpenJDK) is what expectd to be supported.

The requirement is really for "OpenJDK", and not "AdoptOpenJDK". Can this please be corrected. Jira appears to have the correct messaging. If there is some reason that OpenJDK as available in distributions such as RHEL is not acceptable, please provide information about what this would be so that we can prepare for it. Otherwise, we plan to use OpenJDK, and we are expecting that Atlassian does in fact support OpenJDK now and it is a documentation error that only AdoptOpenJDK builds of OpenJDK are supported.

https://confluence.atlassian.com/doc/confluence-6-13-release-notes-959288785.html It looks like OpenJDK support is now official.

Is this OpenJDK support added to Confluence 6.13 now officially? Confluence 6.13 was release today but the ticket is still in progress so wondering...

So, if I did understand the above update note correctly, the development is planning to migrate in the foreseeable future, yes...? (Thus avoiding the Oracle licensing issues). If that is correct, it is great news, thanks!...