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.

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

HI whitford, please note at the bottom of the readme it states "This Docker image is great for evaluating Confluence, however it does use OpenJDK which is not supported for running Confluence in production."
Stay tuned however!

This issue seems dated because the Docker Confluence Server project is using OpenJDK! So it must be OK now. How about we update the Supported Platforms page?

Both Java 8 going EoL and Oracle charging for it from January 2019 onwards are major indicators to get out the middlefinger, point it towards Oracle and migrate to something else.

Otherwise your product gets MASSIVELY more expensive from that date onwards.

OpenJDK seems like a more than obvious choice here.

We are using Jira and Confluence on Windows, based on the below table, licencing for Atlassian products that do not support OpenJDK is about to get very expensive.

People have mentioned that they are running your products on Linux with OpenJDK with some success, we could research and test this internally, it's time and money we didn't budget. If OpenJDK is not made a supported JDK soon, it will result in us having to review all solutions including alternative platforms. New Atlassian licence purchasing is on hold now.

https://www.aspera.com/en/blog/oracle-will-charge-for-java-starting-in-2019/

*Note:
A: The Named User Plus minimum for this program is 2,000 NUP licenses. 
B: The Named User Plus minimum for this program is 10 NUP per Processor.

Not sure if my other conversation about openJDK would be of interest to anyone.   Here is the link: https://community.atlassian.com/t5/Confluence-questions/OpenJDK-support-plans/qaq-p/784851?utm_source=atlcomm&utm_medium=email&utm_campaign=immediate_general_reply&utm_content=topic#U787433

Oracle is changing (or changed) their Oracle JDK support structure.  We need to buy Oracle JDK licenses (not just the support contract) from Oracle JDK 1.8 onwards.  This is going to make Atlassian product deployment using VMs very costly since Oracle doesn’t recognize VMWare VM technology and need to pay for all the physical cores on the ESXi servers.

Not to pile on, but Oracle just announced a few days ago that effective January 2019 anyone using their JRE for commercial purposes will require a commercial license. What does atlassian plan to do about that?

Officially supporting OpenJDK would also make Confluence compatible with more platforms, such as FreeBSD, i.e. we run Bitbucket with OpenJDK in a jail on FreeBSD, and on ZFS, what a delight !

Been using confluence with OpenJDK for a week now. Be aware that Microsoft fonts (for document preview) are bundled with Oracle JDK. They need to be made available on the OS and licenced. Without them, the preview still shows readable text but in a strange default font.
Apart from that, no complaints so far.

Officially supporting OpenJDK would make deploying Confluence much much easier with Docker. Since it seems to be working anyway, please fix this.

1. PA-40960

FWIW I have been running Atlassian products on OpenJDK on FreeBSD for 8 years now. I've not once had an issue that was related to OpenJDK doing something "wrong" compared to Oracle (and back when I started, Sun) JDK.

I have to do nothing special to make it work for Confluence. For Jira I have to hack the "check-java" script so matches the version string OpenJDK emits.

Also, as of several versions now, OpenJDK is identical to Oracle JDK other than the license and support. They are built from the same source code.

Yes, my image stay private, as "only me" accept the oracle licence.

Be advised that you are in breach of Oracles license if you publish a docker image which includes Oracle JDK. 

Hi,

for now, in order to use Oracle's JDK on docker for confluence , I patch the dockerfile each time and make my own image

ENV GLIBC_VERSION=2.26-r0

RUN apk add -update libstdc++ curl ca-certificates bash && apk del libc6-compat && for pkg in glibc\${GLIBC_VERSION} glibc-bin-\${GLIBC_VERSION} glibc-i18n-\${GLIBC_VERSION}; do curl -sSL https://github.com/andyshinn/alpine-pkg-glibc/releases/download/\${GLIBC_VERSION}/\${pkg}.apk -o /tmp/\${pkg}.apk; done && \
apk add --allow-untrusted /tmp/*.apk && \
rm -vf /tmp/*.apk && \
( /usr/glibc-compat/bin/localedef --force --inputfile POSIX --charmap UTF-8 C || true ) && \
echo \"export LANG=C\" > /etc/profile.d/locale.sh && \
/usr/glibc-compat/sbin/ldconfig /lib /usr/glibc-compat/lib

COPY jdk /opt/jdk
ENV JAVA_HOME /opt/jdk

Let's be honest here, this requirement is completely artificial, it's just something Atlassian can use to deflect support queries, making you chase down a futile path to get support (which you already pay dearly for).

I challenge anyone to give a good technical reason for why running Atlassian products on OpenJDK is somehow worse than running it on Oracle. There are plenty of reasons however to use OpenJDK, one being docker (which Atlassian uses in their docker images) and the other being that upgrading is a lot easier. 

This is one of the very frustrating, long-standing issues that I have been facing that make installing and maintaining Atlassian products an uphill battle - another significant issue being the crummy MySQL support with regards to unicode with unnecessary health checks spreading FUD for the Jira administrator (who might not be a MySQL expert). 

Atlassian's official Docker image uses OpenJDK for licensing reasons and is built on Alpine for compactness. The most accessible instructions for switching to Oracle's JDK are not longer accurate due to changes Oracle has made to how they distribute their images. The currently available Oracle images are built on OracleLinux, which cannot be used as a base image for the official Confluence image because it assumes Alpine...

Confluence would be immensely easier to manage if we could use Docker, but the lack of support for OpenJDK is a huge obstacle.

Just checked, FishEye and Bamboo already support OpenJDK Leaves confluence + jira please thx

Important news for Redhat users: Redhat is going to stop offering Oracle Java via RPM in november 2018 and recommends switching to OpenJDK: https://access.redhat.com/articles/3322051.

So this is becoming a cost issue as well, as we'll have to pay for Oracle licences on a per server basis. Please start supporting OpenJDK soon - for all Atalassian procucts (we are using Confluence, Jira, FishEye, Bamboo)

For what it's worth I've been running many Atlassian products including Confluence on OpenJDK without incident.

There are no feature or performance difference between Oracle JDK/JRE and OpenJDK, and since OpenJDK is the reference implementation I think it would be prudent to use this as the default platform instead of the proprietary version, which is pretty much obsolete and somewhat problematic when using containers since you would have to pay license fees when publishing a container image. 

Not sure why I get this error in the Docker container .... built by Atlassian

Interestingly enough, Oracle has decided to start going after people for Java licensing. I think Atlassian really needs to relook at supporting openjdk as well as mariadb in the future.

Please provide an update/feedback!
Are you planning to support openjdk?

I am also wanting to know the status of this?

Providing OpenJDK support seems a key thing when considering licensing challenges when trying to run Java in Docker. See https://github.com/cptactionhank/docker-atlassian-confluence/issues/29 for the issue in the unofficial Confluence Docker image.

For reference, a popular opinion: http://blog.takipi.com/running-java-on-docker-youre-breaking-the-law/

Any updates / thoughts on this one?

Any news on this subject ?

What is the actual status of this? I would really appreciate if OpenJDK is finally (official) supported as it is with crowd!

For those using Ubuntu, until this request is fulfilled, here are some easy steps to get Oracle JDK running: http://www.ubuntugeek.com/how-to-install-oracle-java-7-in-ubuntu-12-04.html.

I've been running Jira on FreeBSD for about 4 years now. No issues. Currently I run Jira 6 (and confluence and crowd) on FreeBSD 9.1 using OpenJDK 7. Everything just works. Having official blessing would be grand.

pvanulden, we were using Diablo JDK commercially for two years, and it wasn't reliable enough. ZFS is the most valuable feature of FreeBSD, and that's why we prefered to use it - but Diablo JDK was causing more and more trouble when number of JIRAs and Confluences grew. Just to name a few problems with Diablo:

• separate scheduler thread's death (Confluence)
• various out of memory exceptions when there is enough memory (both)
• hangs without any reason in the log file (both)
• connection pool problems (both)

All problems gone on official Java on Linux. I suggest not to use Atlassian applications on FreeBSD with Diablo. Let's wait for OpenJDK support.

BTW, we were also trying Oracle Java through Linuxulator and it didn't work reliable enough either. Linuxulator doesn't implement all Linux kernel syscalls, and JIRA/Confluence may go off at any time it tries to use it. For instance, Bamboo won't even start on OpenJDK @ Linuxulator.

For the record, we've been running both Jira and Confluence on OpenJDK for the past couple of weeks. No noticeable issues as of yet.

We've been running both Confluence and Jira on FreeBSD using the diablo-jdk16 port for some time now with no issues. Unfortunately, diablo-jdk16 is now deprecated/expired so we are no longer able to upgrade it. I'm planning on giving openjdk a whirl to see if that works. Hopefully we will see some official support from Atlassian before long!

Support for OpenJDK would mean that Confluence can be run on FreeBSD without any problems.

We are facing this very issue. We confluence, jira and crowd which are currently running under a vulnerable version of Java. We can't upgrade as Debian Security doesn't want to pull the changes because Oracle have changed the licensing, therefore I am looking at OpenJDK.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645881

We run several apps on Ubuntu 10.04 LTS systems: Confluence, JIRA, Wowza Media Server.
A couple of weeks ago I replaced the sun-java6-jre with open openjdk-6-jre-headless on the three machines in question.
They all work fine with openjdk.
The only issue I had were some errors because of missing fonts, but after installing ttf-dejavu that was fixed as well.

https://confluence.terena.org runs Confluence 4.1.2.

Given the Sun java license change, linux distributions do not ship the Sun JDK anymore http://mrpogson.com/2011/12/14/sun-java-no-longer-welcome-in-debian-gnulinux/, https://lists.ubuntu.com/archives/ubuntu-security-announce/2011-December/001528.html. This would mean that installing/maintaining confluence on linux servers will require a tad more effort, unless alternatives such a openJDK are natively supported...

+1 for supporting openJDK!

I'm now running successfully locally on Ubuntu 10.04 LTS with OpenJDK 1.6.0_20 (64 bit Server VM).

James, to be honest we're not aware of the current status of running Confluence with OpenJDK. Feel free to post any results on this ticket.

In practice, "Not Supported" means that you'll be asked to switch to a supported configuration if you have a problem and want to get help from our support team. On our side, we don't test on anything that isn't supported and we won't look into problems that only affect unsupported platforms.

At the moment, we don't have any plans in the short term to extend support to OpenJDK. Just looking into issues with the platforms we currently support is keeping us very busy.

Can anyone tell me if "Not supported" means there is no official support if anything goes wrong, - but you can give it a try, or does it mean "This doesn't work - don't even both trying to run start-jira.sh"?

I suspect most people don't realize that OpenJDK isn't fully supported, which is unfortunate. It's the easiest way to automate an installation of a server, since most systems required acceptance of an EULA for the Sun JDK.

Referring documentation:

• http://confluence.atlassian.com/display/DOC/Installing+Java+for+Confluence
• http://confluence.atlassian.com/display/DOC/Installing+Confluence+Standalone+on+Unix+or+Linux