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?
I know Willem and I have both been doing a bunch of experiments with Java8. The main blocker we have right now is all the JIBX related stuff as the JIBX plugin cannot work with Java8. It’s pretty much out of our hands (and not really even in the JIBX’s folks hands) as it would require a release of BCEL from the Apache Commons folks first. I *think* if a BCEL release was made, we could at least build CXF with Java8. That would leave a couple remaining issues: CXF’s use of JAXB - we pull in the jaxb-impl and jaxb-xjc from Maven central. Those versions have problem with the secure parsers. There are two options: 1) wait for Oracle to release new versions to maven central, or 2) Update to use the ‘internal’ versions from the JDK. (or (3), set the system property, but that sucks) There might be another option of doing DOM parsing ourself with Woodstox and just return DOM’s, but I haven’t looked enough into JAXB to know if that really would work. Anyway, #3 on my list was partially to help with the Java8 issues. (note: this can also be “fixed” by throwing xercesImpl onto the classpath, but I’m kind of loathe to mandate that as well) 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. I’m pretty sure most of our tests pass OK with Java8 right now. It’s mostly just the build time issues and likely the DynamicClient (due to invoking JAXB), and any tests that parse/process schemas (wsdl2java, wadl2java, etc…) that would have issue. 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. :-) > > > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
