Drop Java 5/6 support in Openfire

Good points. Perhaps we can adobt a policy of supporting 1 pervious version of Java after Oracle has EOL’d it for 1 year (to give users a chance to upgrade/update stuff)? This policy would have us drop J5 support for all projects immedietely… and a year from now j6 would be dropped and we’d pickup J8 support and continue with J7 until 1 year after Oracle EOL’s it… so-on and so-forth.

Maintaining support for EOL’d technologies would be like us trying to ensure code ran on IE6 or something… at some point, it just needs to go away.

So, last week Spark installers have been modified to require Java 7 and Spark only runs when Java 7 is bundled or installed on the system. So i will be closing SPARK-1545 after more testing. Openfire still can run on Java 6. I’m speaking about the installer, not the code still using old java features, it’s a separate issue. Should we also move Openfire build plan to Java 7? Of couse, many admins are still running Openfire on boxes with some 5 years old never updated Java 6. So when releasing new version in the blog post we should warn, that it won’t run with Java 6 (at least on Windows, not sure about the linux or tar.gz variants). This will hurt some users, but i think it is better for all to be on the same page, so when someone reports an issue i don’t have to think is it some Java 6 related issue. There were such issues with Spark, but it is a GUI application and Openfire is probably less affected by that, but still…

It will hopefully hurt nobody getting rid of old, insecure and out-dated program versions. If one wants to use Java5 one should use Jive Messenger/Wildfire and not Openfire. So also for Openfire one could configure the build scripts to build Java7 code.

I am all for moving our bamboo builds to Java7. The decision is up to Guus.

The important bit here is to not make life difficult for our “customers.” We might not agree with their policy to use an ancient version of Java, but sometimes, that cannot be helped.

As long as there is no functional reason to upgrade to a later release of Java, we should not require one.

That said: there will be a functional reason to upgrade to Java 7 in the future. It will, however, require quite some code modifications - something that I would like to see happen in a version that is the next major release: 4.0.

In conclusion: let us leave the Java support as-is for the 3.x branch and move to 7 (or 8, if that brings functionality we want to use) in the 4.x branch.

besides language features, the new java versions bring large performance improvements to the jvm and javac compiler optimizations. so even for a java 5/6 codebase (like Spark is), there is still benefit from simply running on a more modern jvm, as well as benefits from compiling with the newer javac.

… just thoughts on the topic. Openfire is very stable for me as-is

You’re absolutely right. That’s why we ship JRE7 with Openfire.