Java 8 support

This thread should be used for discussing Java 8 support and bundling in Openfire.

JIRA ticket tracking this OF-767

The should be understanding that we are discussing Java JRE JVM issue, not the Oracle’s Java Browser plugin’s security issues, which is completely unrelated to Openfire.

Are there any known issues, that Openfire does NOT run with Java 8?

I haven’t tried it yet myself (nor running with jre 8 neither compiling with jdk 8). Maybe this evening. I think this ticket is mostly about bundling Openfire with JRE 8. It should be backwards compatible with Java 7 functions.

A skim of the release notes indicates most things should “just work”. However they did do some refactoring of a lot of the core libs, and some issues may arise.

A quote from the release notes:

Java SE 8 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 8 without modification. However, there are some minor potential incompatibilities in the JRE and JDK that involve rare circumstances and “corner cases” that are documented here for completeness.

java8’s release notes make for an impressive update to java.

Notes about compatibilty and what exactly change:

Compatibility Guide for JDK 8 #A999198


Release Notes;

http://www.oracle.com/technetwork/java/javase/8train-relnotes-latest-2153846.htm l

What's New:

http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html

Compatibility Guide:

http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html

Known Issues:

http://www.oracle.com/technetwork/java/javase/8-known-issues-2157115.html

Thanks for the links. I forgot to link the JIRA ticket which started this discussion (did now). I’m still waiting on some proven security threat that can affect Openfire while still using Java 7, or even Java 6. And i’m curious which changes will improve Openfire performance/stability/etc. I would be glad, and newer version should improve something. But it can also brake something. And some users might still want to use Java 7 and still get the newest features and bug fixes. So it must be investigated by developers and carefully adopted.

I know we’ve just recently dropped Java 6 support in Spark, but maybe we should at least wait till Java 7 is EOL’d and Java 8 become more mature. Not sure about Java 6 though. How many users need it. There is still even a Java 5 support in there OF-466

Btw, Openfire is bundled with Java 7 for a long time.

CSH wrote:

Are there any known issues, that Openfire does NOT run with Java 8?

I’m not a developer or an expert, but Openfire and Spark seems to run ok with Java 8. Also had no problems compiling Openfire and Spark with JDK 8 (other than obviously adding java 8 check to the build.xml). Shows the same warnings while building like it does with JDK 7

I have been running JRE8 on one of my openfire servers since early release with no problems. Now that it has been released, I am upgrading all my servers with no problems so far

See pullrequest https://github.com/igniterealtime/Openfire/pull/8

Without the change OF is not compiling. With the change I’ve compiled it successfully with oracle jdk8.0.5 and started it localy on my machine.

Thanks - will merge the pull request shortly.

Uups, I think I was faster ;-). I did read your comment just yet.

Good problem to have! Thanks for taking care of this.

Thanks.

But there is another error and I doesn’t saw it because in general a build without javadoc generation is started:

The guys from oracle added ‘doclint’ and this breaks our build with 100 html-errors in javadoc comments. The bad think on that change is: Java7 reports an error if the parameter is set.

I know about this issue. In Maven you can disable it if built with JDK 7 and enable it when built with JDK 8. I don’t know about Ant, though.

That’s ok (i have fixed my build.xml locally after upgrading to jdk8). But probably this is not enough to close the ticket. We should probably start bundling Openfire with jre8 at some point. Not usre, but this probably depends on what version install4j provides for the build. I saw in its changelog, that it supports 8 now, but probably Daryl can shed some light on this. My test server is running ok on jre8. Probably there is not much what should be done to support it. But we should leave java7 support in place (i mean it shouldn’t force to use java8). I have marked the ticket for 4.0.0, but we can change it to 3.9.3 or 3.9.4.

I think we couldn’t switch to Java8 on all OS. There is not OpenJDK8-Package in Ubuntu Wheezy or the current Ubuntu.

We should bundle Java7 (and drop Jdk5 and 6) and discuss in 6 Month again.

I updated install4j on ignite’s bamboo yesterday, so it should support java8 builds, but I don’t have java8 installed on any of the bamboo hosts at this point.

Hello guys,

It is ok for next version?

Attention : Java 7 EOL is very soon: Oracle Java SE Support Roadmap

Java 8 is perfect for launch the new manifesto with more security.

Thanks in advance.

Regards,

Neustradamus

fyi…I still need to do some more testing, but it appears that java 8 and spark breaks SSO.

speedy, do you mean using Java8 with Spark or when Openfire is using Java8? This thread and ticket is related to Openfire only.

Last time i’ve checked (like a month or two ago) Java8 still had experimental status. And now they are EOLing java7 in a few months Probably java8 will become stable in that same moment… I’m fine with java8 (been using it for 4 months with Openfire 3.9.3 with no problems) and especially when you can easily remove bundled java and use system one i see no problem neither in bundling java7 or updating to java8. This means, that Openfire should still WORK with java7, as i bet many users still have to use java7 for some reason (on Linux Oracle packages are pain and i feel OpenJDK not always works fine…).

Speaking about the security… Will anyone tell me what flaws java7 bundled with Openfire has? Openfire is not a browser and Oracle’s Java browser plugin is not bundled. So what’s the real threat? Unless java8 deals better with all the SSLv2/3, POODLE stuff and has weak ciphers disabled by default.