Well, older versions of CXF--2.3.x and earlier--of course would
perpetually support JRE 5.0. It's just a question of moving forward, it
looks like right now 2.4 will still support 5.0 and maybe we'll switch
to 6.0 minimum in CXF 2.5. I didn't know about royalty concerns (do
you have a link for that--can't immediately find anything off Google),
but I'm sure there would also be some fears of running on an
unmaintained JRE. Although some wish/need to remain on JRE 5.0 (and
hence CXF 2.3), there's also a counterargument, that for information
security reasons, newer releases of CXF shouldn't allow itself to be run
on unmaintained JRE's, similar to the way responsible builders will not
put up homes on unsafe land/foundations even if business is lost as a
result.
Glen
On 2/22/2011 9:27 PM, Fred Dushin wrote:
Speaking from the field, you do not want to drop 1.5. There are organization
out there that are not moving to 1.6 (or are moving very slowly) out of fear of
Oracle's collecting royalties under the 1.6 redistribution terms.
CXF is meant to be an embedded library. If you drop support for 1.5, you will
find users who will not upgrade. At a minimum, CXF should support 1.5 on one
of its branches.
Not everyone out there has the luxury of being on the bleeding edge.
-Fred
On Feb 22, 2011, at 11:17 AM, Daniel Kulp wrote:
On Tuesday 22 February 2011 3:45:44 AM Christian Schneider wrote:
Hi all,
now that camel dropped Java 5 I am asking myself when will we also drop
support for Java 5 in CXF? As CXF 2.4.0 allows some bigger changes than
a minor version we could do that in my opinion.
Well, I guess the question is: what is the cost of supporting Java 5 compared
to the cost of dropping it? For Camel, the cost was pretty high as they had
some dependencies for various components that required Java6. Thus, you
really couldn't do complete Camel builds with Java5 anyway.
CXF is a bit different. RIGHT NOW, we don't have anything anyplace that
requires Java 6. In generaly, the only "cost" we have is the occasional
@Override annotation that Eclipse likes to stick on everything causing a
Jenkins build break and some slight additional complexity in the poms. Thus,
the cost of supporting Java5 for us is pretty low, right now.
Dropping support for Java5 would cause issues with SOME people, especially
those trying to use CXF in some of the older App servers. Also, to be
honest, the new JAX-WS and JAXB 2.2 stuff in CXF works a TON better with Java5
than with Java6 due to the endorsed crap. Dropping support for Java5 would
mean much of the JAXWS 2.2/JAXB 2.2 would not be tested on a day to day basis
as that stuff is currently only tested when run on Java5. Thus, there is a
big cost of dropping it just from a testing and support standpoint. Getting
that stuff to run on Java6 properly would likely require a lot more
configuration in the poms, updates to our plugins, likely updates to some of
the Maven plugins, etc.... Basically, it's not easy.
Thus, in my opinon, I don't think *right now* is the right time to drop
support for Java 5. Maybe for 2.5, but likely not for 2.4. That said, I
could potentially be convinced either way. :-)
--
Daniel Kulp
dk...@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
