Hi Dan,
Gotcha, thanks a lot for thorough and detailed explanation.
Thanks!
Best Regards,
Andriy Redko
DK> On May 19, 2014, at 2:54 PM, Andriy Redko <[email protected]> wrote:
>> Hi Dan,
>> Excellent plan! One question though: following recent discussions on the
>> list,
>> there is strong interest in Java 8 support but we know some issues have to
>> be resolved.
>> Do you think we can at least investigate Java 8 support and be ready as much
>> as we can?
DK> I know Willem and I have both been doing a bunch of experiments with Java8.
The main blocker we have right now is
DK> all the JIBX related stuff as the JIBX plugin cannot work with Java8. It’s
pretty much out of our hands (and not
DK> really even in the JIBX’s folks hands) as it would require a release of
BCEL from the Apache Commons folks first.
DK> I *think* if a BCEL release was made, we could at least build CXF with
Java8. That would leave a couple remaining issues:
DK> CXF’s use of JAXB - we pull in the jaxb-impl and jaxb-xjc from Maven
central. Those versions have problem with
DK> the secure parsers. There are two options: 1) wait for Oracle to release
new versions to maven central, or 2)
DK> Update to use the ‘internal’ versions from the JDK. (or (3), set the
system property, but that sucks) There might
DK> be another option of doing DOM parsing ourself with Woodstox and just
return DOM’s, but I haven’t looked enough into
DK> JAXB to know if that really would work. Anyway, #3 on my list was
partially to help with the Java8 issues.
DK> (note: this can also be “fixed” by throwing xercesImpl onto the classpath,
but I’m kind of loathe to mandate that as well)
DK> Other third party things: I’m not sure what the Java8 status is for things
like the version of Spring we use, the version of Jetty, etc…. Definitely a
testing effort.
DK> I’m pretty sure most of our tests pass OK with Java8 right now. It’s
mostly just the build time issues and likely
DK> the DynamicClient (due to invoking JAXB), and any tests that parse/process
schemas (wsdl2java, wadl2java, etc…) that would have issue.
DK> Dan
>> Thanks.
>> Best Regards,
>> Andriy Redko
>> DK> Just wanted to throw out a quick discussion about how to manage the git
>> repo for the short term.
>> DK> With the last 2.6.x release, we announced there would be one more
>> release of that branch. Thus, we need to keep
>> DK> that branch around. To avoid having to merge to 3 fixes branches, I’d
>> like to keep master on 3.0.1 until 2.6.15 is
>> DK> released. At that point, we can create the 3.0.x-fixes branch and set
>> master for 3.1. Is there any problems
>> DK> with that? Anything needed for 3.1 that needs to be put on master
>> immediately?
>> DK> With 3.0.0 out, I expect a bit higher uptake of it and a possible influx
>> of issues. Thus, I’d like a relatively
>> DK> quick turnaround for 3.0.1. Maybe 4-6 weeks. At that point, we could
>> do 3.0.1/2.7.12/2.6.15 releases at once and be done with 2.6.x. Would
>> that work for everyone?
>> DK> Once we start 3.1, I’d like to do a couple things:
>> DK> 1) Update to require Java7
>> DK> 2) Remove all the Jaxws 2.1 support stuff. With being Java 7, we don’t
>> need the various 2.2/2.1 profiles and differences and such.
>> DK> 3) *possibly* change the tooling to use the in-JDK JAXB XJC. With
>> recent versions of the JDK, the in-JDK versions
>> DK> are actually more up to date than the versions available in central.
>> Plus, this would fix some of the issues on
>> DK> Java8. This MAY cause issue on IBM JDK’s. Will need to investigate.
>> Possible wrap the impl via reflect calls
>> DK> like we do in the runtime. In any case, this would drop a few
>> dependencies as well.
>> DK> 4) Start investigating Jetty9 support. This may be hard without
>> breaking Jetty8.
>> DK> 5) With Java7, start using some of the new interfaces, the AutoClosable
>> one being the main “nice to have”.
>> DK> Anyway, open for discussion. :-)
