So, i wanted to discuss this with the community and developers. maybe it is time to drop Java 5/6 support from Openfire? Say for 4.0.0 version? Now some developers has to do this OF-691 to comply with ages old Java 5. Java 6 is also long time EOL. I have already filed same for Spark - SPARK-1545. Old java makes old bugs and issues come up again. Old version would still have old java support, so i see no point in supporting that for newer versions. Unless it is too much work to drop it.
I would be happy to see Java 5 and 6 go away, but I suspect the problem is the many platforms out there that do not support Java 7 ?
Maybe some plaforms still need Java 4 It’s good to be flexible, but if it requires to make workarounds/hacks and you can’t use new features of Java 7, then… I think it is sufficient to have Openfire 3.8.2 with Java5/6 and new versions with only 7. It’s like still supporting IE6 or .NET 1/2. Things has to go away at some point. We can do a poll (again), but probably people really needing old java won’t vote
Actually there is one old poll http://community.igniterealtime.org/polls/1025
Most have voted to move to Java 6 then. Maybe we can at least drop Java 5, or vote for moving to Java 7.
We tried to move our development efforts to Java 7 but we found that devs running Snow Leopard didn’t have an easy upgrade path. Not the end of the world but it’d be terrible if one of the key maintainers suddenly couldn’t build Openfire
1 Like
Java 7 is fully supported on Mac at this point. Making the switch would be a nice move, especially since support for Java 6 and earlier has ended.
+1 for moving to Java 7 … I think it would help us continue to “freshen up” this important project. I’ve definitely bonked on the limitations of the older JDK a few times.
Moving to a newer version for Java is something I’ve been considering for Openfire, if only for the new XML parsing functionality (StAX) that’s included in later versions.
So, do we poll, do we ask for more comments/ideas, do we file a ticket and schedule for the next major version? Most importantly, who will do it?
Do we need really need more input? I would be happy if each of the teams simply made an announcement as part of the release that introduces the new dependency. For Openfire, that’s likely going to be version 4.
I’m fine with that. What projects need this change? Smack, Tinder also?
I will ask Walter if it is fine to push Spark’s ticket for 2.7.0 version.
Guus, you can file a ticket for Openfire 4.0.0
I think that moving OF and Spark probably make sense, since they are deployable entities on their own. The only real factor that would impact this decision is OS support, which is probably pretty much everything by now.
The same doesn’t hold true for libraries like Smack and Tinder. These have to work in existing software platforms and applications. They have to maintain a balance between using current tools (i.e. Java 7) and being compatible with the broadest range of applications.
So the question for me would be what the current adoption rate is for Java 7 in production environments?
In addition, I am also not sure about the compatibility of Java 7 and Java for Android. Currently Smack is being repackaged (by Flow as asmack) for usage on Android as well.
Isn’t Java 6 no longer supported by Oracle? Why would production sites run a platform not getting security updates?
I wonder if Spark issue with searching and using Java 6 on startup is not related to Smack itself (only someone knowing Spark souce can tell). If we can drop support from Spark/Openfire and Smack or Tinder won’t affect it by still having Java 6 support, then i’m fine.
If I was a betting man, I would put money on more production code running on Java 5 than Java 7. I would guess that the vast majority is actually Java 6 though.
OK, although not specifically production code, this survey of over a thousand java code bases does show that I would lose my bet on usage at least, but it does support my suspicion that Java 6 is the most widely used.
I am having trouble finding any other listing of such statistics, which would prove helpful.
Does everyone agree to at least drop Java 5? If so, I’ll update bamboo for this
I think that’s a safe bet at least.
dropping java 5 and 6 is a good thing imho. Supporting versions that Oracle itself no longer supports will only cause more of a headache… not only from a security standpoint, but from a features standpoint. Java 5 and 6 simply can’t do some of the things Java 7 (and soon 8) can do.
For example, ARM blocks (Try with Resources) are great! But only available in j7+. When the time comes, Java 8 will support lambda expressions, etc. In Java 7 the GC was improved as well as the JVM itself had a lot of performance improvements. Many XML improvements as well (JAXP, JAXB, JAX-WS)
Full list of improvements and features: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html
the only drawback I can think of is if people try to run any of the igniterealtime.org software on systems where Oracle has dropped java support from (such as win 2000). However, we can simple say version X of software Y is the last Java 6 supported version, so those users live on that version until they upgrade OS’s.
EDIT: Oh ya… almost forgot! JavaFX is increadibly awesome and makes creating rich GUI’s very simple and easy (much unlike Swing). JavaFX can also run in the browser (similar-but-not-really to an applet). JavaFX only will work with J7+…
Message was edited by: Jason
I don’t think there is any question that Java 7 would be preferable and has more features/capabilities (it would be pretty dissappointing if it didn’t).
The point is whether it is the right time to force the users (of Smack and Tinder) to have to use Java 7. The library being coded to Java 6 does not prevent them from using it in Java 7, so it makes it compatible with both 6 and 7, whereas coding it to be 7 makes it compatible for that version only, thus shutting out the users that are still using Java 6, which I believe to be a much larger user base than 7 at this time.
Assuming that Java 7 is available for all widely used OS’s though, I don’t see any reason that deployable applications like Spark and Openfire can’t move to this version.