I think, if only because of the nontrivial amount of upgrade work Dan
was mentioning earlier, we'll be keeping 1.5 at least for CXF 2.4.
I do have a philosophical concern about staying *too* much in the past
though. In my view, for the open source model to work, it needs to be
for the benefit of both the user community and the committers working on
it. Committers should be better skilled/better marketable as a result
of their volunteer efforts (much in the same lawyers become with pro
bono work), and if the API lags too many years behind present
technologies you end up having a smaller committer pool and hence a
less-valuable product (even if it works with older Java versions). To
give an extreme example, users who can't leave the Commodore 64 may need
to look for a commercial solution rather than us trying to recruit
committers into supporting it to their own personal detriment. Stated
another way, rather than ask "What's good for the users?" a better
question might be "What's good for the users *and* committers?"
Glen
On 2/27/2011 6:44 AM, Benson Margulies wrote:
I am opposed to dropping 1.5. There are a surprising number of people
out there who have barely bothered to stop requiring *1.4*. We could
put the animal sniffer to work to help head off any unfortunate
accidental dependencies on 1.6 APIs.
On Wed, Feb 23, 2011 at 7:53 AM, Glen Mazza<gma...@talend.com> wrote:
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
--
Glen Mazza
Software Engineer, Talend (http://www.talend.com)
blog: http://www.jroller.com/gmazza
