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 > > >
