With the release of Apache CXF 2.6.1 last week, the CXF community decided to create the 2.6.x-fixes branch and move trunk to target 2.7. One of the first things we’ve started working on for 2.7 is dropping support for Java5. This is a topic that has come up many times over the last year or so, but it’s something we’ve tried to delay as long as possible as we do have users that still use Java 5. However, we’ve finally reached a tipping point where the community feels we need to move forward with Java6/Java7 only.
There are a few reasons:
- External deps – CXF uses a bunch of party deps like Jetty, Spring, WSS4J, GWT, ActiveMQ, etc… Some of these have already gone Java6 only (Jetty 8, ActiveMQ and GWT for example) so CXF has been locked down to some of the older versions. To continue getting enhancements and fixes for some of those libraries, we need to update.
- WSS4J 2.0 – WSS4J 2.0 which will introduce much faster and scalable ws-security processing has already decided to go Java6. It’s unknown yet whether WSS4J 2.0 will be ready for CXF 2.7, but to start working on the integration would require Java6.
- Build system – Java 6+ contains a bunch of the dependencies that CXF needs “built in”. Things like SAAJ, Activation, jaxb-api, etc… We had some profiles in the poms to detect the JDK and add those deps if running on Java5. Removing those profiles removed hundreds of lines from the poms.
- Simplify some code. There are a couple places in CXF where we had to resort to using some reflection to call off to Java6 API’s if running on Java6 and provide an alternative path if not. We are now able to cleanup some of that.
- Deployment environments going Java6 – the popular environments that CXF is deployed into have also gone Java6 only or will be shortly. That include Jetty 8, Tomcat 7, Karaf 2.3/3.0 (coming soon), JBoss, etc… Even Karaf 2.2 which does support Java5 has a few features that only work with Java6.
- Quite honestly, none of the CXF developers use Java5 on a daily basis anymore. We’ve all moved onto using Java6 (or even Java 7). Thus, the primary Java5 testing is now done by Jenkins and the developers only fix things if Jenkins finds an issue. Dropping Java5 simplifies life for the CXF developer community.
In anycase, this is something that’s been a long time coming, but it’s not something that will affect people today. In 5 months or so when CXF 2.7. is released, people will need to decide what to do then. However, keep in mind CXF 2.6.x will continue to support Java5 and will likely be supported for at least another year. The clock is now ticking though. Tick…. Tick…. Tick…. 🙂