Request: Supporting OpenJDK due to changes in Ubuntu repos

I’ve been looking to take advantage of Openfire more on my Ubuntu based server and the big question that remains for me is support of OpenJDK 6 and 7. Right now, Openfire officially supports only the sun-java6 versions of the JRE but recently Oracle stopped updating the JRE and JDK in the Canonical Parters repository at http://archive.canonical.com/pool/partner/s/sun-java6/ for ALL versions of Ubuntu.

Seeing this and continuing forward with supporting Openfire on future releases of Ubuntu, how much work would it take to have Openfire also run well on OpenJDK’s JRE? In the past I have altered Openfire config files and force installed Openfire to use OpenJDK and although it worked, there were some warnings from Openfire about it not running off a proprietary JRE.

With a LTS version of Ubuntu (12.04) coming out in under six months with 5 years of support, I think it is very important to support OpenJDK with Openfire to not only ensure its future, but the openness of open sourced software in the Linux ecosystem.

1 Like

As currently we don’t have active developers, it depends whether someone provide a patch for such support or not.

I am running openfire over openjdk6 right now. It seems that basic functionality is working.

What are some elements of Openfire that you are not using? I am very curious becuase I want to go back and test the elements that you do not have enabled to see if I run into issues.

I’ve read somewhere that there were some bugs in OpenJDK 6 and Sun Java 6 with more advanced functionality (regarding sockets or whatever) that were fixed in OpenJDK 7 and Sun Java 7.

Of course I cannot confirm this issue with the 6 series and it must be somewhere in these forums or release notes.

Teg,

are you having any specific issues running Openfire with OpenJDK6? If so, what is this? Are you getting some exceptions, crashes?

I had it run off of the Sun 6 JRE and switched back to OpenJDK 6 last night and things seem to be ok. Like yourself, I tried this only at the most basic level but I worry if I get too advanced down the future things can break due to it not being officially supported by the team.

In regards to OpenJDK 7, isn’t Oracle using that as its future codebase for their proprietary JDK 7? With that in mind, that means that OpenJDK 7 will probably be more fine tuned and supported than OpenJDK 6 was and the differences between it and the Oracle JDK7 may be nil. That is of course if the Openfire devs don’t go out of their way to have it only work with the Oracle version.

With that in mind, I see no reason to at least support OpenJDK 7 in a future release or at least have it be an option with the differences hopefully between OpenJDK 7 and Oracle’s JDK being small in regards to the JRE.

Here is that link about OpenJDK 7 as the officlal Java SE 7 reference implementation: http://blogs.oracle.com/henrik/entry/moving_to_openjdk_as_the

Ted,

I think things will mostly work fine even with OpenJDK 7 as JDKs tend to have a great degree of backward compatibility. I think we need to understand difference between to possible meanings of to support: one meaning of “Openfire does not support OpenJDK X.Y.” could be “Openfire won’t run at all with OpenJDK X.Y” and the other one is “Openfire developers don’t mostly use OpenJDK in their enviroment, so fixing problems specific to OpenJDK environment may take longer as usual”. I believe it’s the latter, i.e. it is advisable to try a Sun JDK in case of problems to check for regressions.

Recently I debugged a problem on my machine that included going through JDK code (I used OpenJDK 6 and checked with OpenJDK 7) (http://community.igniterealtime.org/message/208678, http://community.igniterealtime.org/message/169697) and it turned out to be a OS bug, not related to JDK (http://svnweb.freebsd.org/base?view=revision&revision=220463). So checking with different JDKs is sometimes worth checking.

Another case for having a future release recognize OpenJDK is whenever I run an apt-get upgrade on my Ubuntu 10.04 server and get this which in return wants me to install sun-java6-jre becuase I have openjdk-6-jre installed instead:

You might want to run `apt-get -f install’ to correct these.

The following packages have unmet dependencies:

  • openfire: PreDepends: sun-java5-jre but it is not installable or*

  •                    sun-java6-jre but it is not installed or*
    
  •                    default-jre-headless but it is not installed*
    

E: Unmet dependencies. Try using -f.

Is there a workaround to stop this or will I have to live with it until there is some patch from the team? Heck, if I had the Oracle JRE 7 would the current 3.7.1 release recognize it?

I think you should report this problem to Canonical and the Ubuntu community.

Since the Openfire .deb file is independent of Ubuntu and not on their official servers, it is not an Ubuntu issue.

The issue is that the .deb file and the program itself once installed is hardcoded with these dependencies for the sun-java5-jre or sun-java6-jre packages. It is now in Ignite’s hands to update the .deb file in a future release and/or allow openjdk 6 and 7 in its dependencies.

I upgraded my system to Ubuntu 11.10 Oneiric with both OpenJDK 6 and OpenJDK 7 installed and when I changed my /etc/init.d/openfire to have this, it still took a preference to OpenJDK 6:

if [ -z $JAVA_HOME ]

then

** t=/usr/lib/jvm/java-7-openjdk-amd64 && test -d $t && JAVA_HOME=$t**

** t=/usr/lib/jvm/java-7-openjdk-i386 && test -d $t && JAVA_HOME=$t**

** t=/usr/lib/jvm/java-7-openjdk && test -d $t && JAVA_HOME=$t**

** t=/usr/lib/jvm/java-6-openjdk && test -d $t && JAVA_HOME=$t**

fi

I have java-7-openjdk-amd64 installed on my system but also noticed there is an **java-7-openjdk-common **folder in /usr/lib/jvm/ as well. I am hoping I am selecting the right folder considering that Openfire 3.7.1 looks for those above and ends up with java-6-openjdk. Either that or the application itself is hardcoded for version 6 of the JRE whether it is OpenJDK or Sun/Oracle.

Here is what I see when I do update-alternatives --config java:

There are 2 choices for the alternative java (providing /usr/bin/java).

Selection Path Priority Status

------------------------------------------------------------

* 0 /usr/lib/jvm/java-6-openjdk/jre/bin/java 1061 auto mode

** 1 /usr/lib/jvm/java-6-openjdk/jre/bin/java 1061 manual mode**

** 2 /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 1051 manual mode**

__Press enter to keep the current choice[*], or type selection number: __

Oh and here is the .deb file where I changed the requirements of it to only look for OpenJDK instead of Oracle and the /etc/init.d/openfire to have the settings listed above: http://ubuntuone.com/7FZiVmWC0qpm31cOsLcZED

Note: Updated .deb download link with Marcin’s changes on Dec 17 following this post

Try this:

if [ -z $JAVA_HOME ]
then
        t=/usr/lib/jvm/java-6-openjdk && test -d $t && JAVA_HOME=$t
        t=/usr/lib/jvm/java-7-openjdk-amd64 && test -d $t && JAVA_HOME=$t
        t=/usr/lib/jvm/java-7-openjdk-i386 && test -d $t && JAVA_HOME=$t
        t=/usr/lib/jvm/java-7-openjdk && test -d $t && JAVA_HOME=$t
fi

Thanks! I originally thought the list order was from highest to lowest, but your method worked and I was able to get it working with OpenJDK 7. Here is what I see when I login to the admin which means it is using it!

Environment
Java Version:
1.7.0_147-icedtea Oracle Corporation – OpenJDK 64-Bit Server VM
Appserver:
jetty/7.0.2-SNAPSHOT
OS / Hardware:
Linux / amd64

Here is the updated .deb: http://ubuntuone.com/7FZiVmWC0qpm31cOsLcZED

Here is a patch for the openfires debian build system. I changes two things:

  1. Only set JAVA_HOME if it’s not already set in debian/rules
  2. Added dependencies for openjdk

The first change is important as currently JAVA_HOME get’s always set to java-1.5.0-sun. Now you can build an openfire debian package with openjdk by issuing

export JAVA_HOME=/usr/lib/jvm/java-1.6.0-openjdk

ant installer.debian

I was able to build openfire this way. But of course the change from SUN’s jdk to openjdk needs some testing.
openjdk.patch.zip (782 Bytes)

Filed as OF-543