I'd love to see use of Optional at least in the Message and Exchange interfaces.
On 29 January 2016 at 13:38, Johan Edstrom <seij...@gmail.com> wrote: > Dan, I like that! > > /je > > On Jan 29, 2016, at 12:30 PM, James Carman <ja...@carmanconsulting.com> > wrote: > > > > Proper Java8 support could give us quite an opportunity here. Marking our > > interfaces as functional (not required of course) and designing our API > to > > be "lambda-friendly" > > > > On Fri, Jan 29, 2016 at 8:24 AM Daniel Kulp <dk...@apache.org> wrote: > > > >> THAT said, I would be OK with going through all the code, removing all > the > >> stuff marked deprecated, update to JDK8, and call it 3.0. :-) It’s > just > >> a version number. We can always do a 4.0 if needed/wanted. > >> > >> Dan > >> > >> > >> > >>> On Jan 29, 2016, at 8:21 AM, Daniel Kulp <dk...@apache.org> wrote: > >>> > >>>> > >>>> On Jan 29, 2016, at 3:21 AM, Christian Müller < > >> christian.muel...@gmail.com> wrote: > >>>> > >>>> Yes, it's a minor release. And regarding to [1]: > >>>> > >>>> MINOR version when you add functionality in a backwards-compatible > >> manner > >>>> > >>>> And that's not the case, if you have to upgrade your JRE. > >>> > >>> How is it not backwards compatible? All of your source that you used > >> with Camel 2.16 should compile and run fine with 2.18. You need to > update > >> your JDK, but the source and API’s and everything are still completely > >> compatible. From an API standpoint, compatible. And the SemVer > thing is > >> all about the API’s. > >>> > >>> > >>> But like was already said, I don’t think we’ve EVER done a Camel > release > >> that didn’t upgrade a dependency in an underlying library that wasn’t > >> compatible. We’ve dropped support for versions of things like jetty and > >> older versions of sl4fj and older versions of Karaf and such as well. > >>> > >>> Dan > >>> > >>> > >>> > >>>> > >>>> [1] http://semver.org/ > >>>> > >>>> Best, > >>>> Christian > >>>> ----------------- > >>>> > >>>> Software Integration Specialist > >>>> > >>>> Apache Member > >>>> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer > >>>> Apache Incubator PMC Member > >>>> > >>>> https://www.linkedin.com/pub/christian-mueller/11/551/642 > >>>> > >>>> On Fri, Jan 29, 2016 at 1:31 AM, Daniel Kulp <dk...@apache.org> > wrote: > >>>> > >>>>> > >>>>> 2.16 -> 2.17 is not a patch release, it’s a minor release with new > >>>>> features and dependency updates and such. > >>>>> > >>>>> 2.16.1 -> 2.16.2 is a patch release. > >>>>> > >>>>> I would agree no changes in JDK requirements on a patch release. A > >> minor > >>>>> release is different. > >>>>> > >>>>> Dan > >>>>> > >>>>> > >>>>> > >>>>>> On Jan 28, 2016, at 5:52 PM, Christian Müller < > >>>>> christian.muel...@gmail.com> wrote: > >>>>>> > >>>>>> I'm with James (even we did it otherwise in the past). A patch > release > >>>>>> shouldn't require you to upgrade your JRE. > >>>>>> > >>>>>> Camel 2.17 = Java 1.7 > >>>>>> Camel 3.0 = Java 1.8 > >>>>>> > >>>>>> May it forces us to work on Camel 3.0 ;-) > >>>>>> > >>>>>> Best, > >>>>>> Christian > >>>>>> ----------------- > >>>>>> > >>>>>> Software Integration Specialist > >>>>>> > >>>>>> Apache Member > >>>>>> V.P. Apache Camel | Apache Camel PMC Member | Apache Camel committer > >>>>>> Apache Incubator PMC Member > >>>>>> > >>>>>> https://www.linkedin.com/pub/christian-mueller/11/551/642 > >>>>>> > >>>>>> On Thu, Jan 28, 2016 at 7:13 PM, Claus Ibsen <claus.ib...@gmail.com > > > >>>>> wrote: > >>>>>> > >>>>>>> On Thu, Jan 28, 2016 at 3:48 PM, James Carman > >>>>>>> <ja...@carmanconsulting.com> wrote: > >>>>>>>> I would rather us bump the major version number if we're going to > >> start > >>>>>>>> requiring users to use Java8. > >>>>>>>> > >>>>>>> > >>>>>>> Yeah that was also my first thought. > >>>>>>> > >>>>>>> > >>>>>>> I would like to keep Camel 2.17 as-is on Java 1.7. Then if 2.18 is > >>>>>>> Java 1.8+ then its much easier to remember as the numbers are > >> aligned. > >>>>>>> > >>>>>>> Camel 2.17 = Java 1.7 > >>>>>>> Camel 2.18 = Java 1.8 > >>>>>>> > >>>>>>> We can always release Camel 2.17 sooner, its been a while since > 2.16, > >>>>>>> so maybe aim for a release in next month? > >>>>>>> > >>>>>>> A reason to keep it on 1.7 is also it would otherwise throw some > >> Camel > >>>>>>> end users under the bus anticipating they can use it on Java 1.7. > >> Then > >>>>>>> we can announce Camel 2.17 would be the last release with Java 1.7 > - > >>>>>>> even ahead of time. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Thu, Jan 28, 2016 at 9:35 AM Daniel Kulp <dk...@apache.org> > >> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> For master (targeting 2.17), I see we’re still setup for Java7. > >>>>> Would > >>>>>>>>> it make sense to move to requiring Java8? We can certainly start > >>>>> taking > >>>>>>>>> advantage of the new things in Java8, but there are also > >> dependencies > >>>>>>> (like > >>>>>>>>> Jetty) that now require Java8 and more and more of them will be > >>>>>>> requiring > >>>>>>>>> that. (example: CXF 3.2 will be Java8 only as well) > >>>>>>>>> > >>>>>>>>> It sometimes makes back merging fixes to 2.16/2.15 tricky if you > >> use > >>>>>>> Java8 > >>>>>>>>> features, but that’s going to be a problem eventually anyway. > >>>>>>>>> > >>>>>>>>> Thoughts? > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Daniel Kulp > >>>>>>>>> dk...@apache.org - http://dankulp.com/blog > >>>>>>>>> Talend Community Coder - http://coders.talend.com > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Claus Ibsen > >>>>>>> ----------------- > >>>>>>> http://davsclaus.com @davsclaus > >>>>>>> Camel in Action 2: https://www.manning.com/ibsen2 > >>>>>>> > >>>>> > >>>>> -- > >>>>> Daniel Kulp > >>>>> dk...@apache.org - http://dankulp.com/blog > >>>>> Talend Community Coder - http://coders.talend.com > >>>>> > >>>>> > >>> > >>> -- > >>> Daniel Kulp > >>> dk...@apache.org - http://dankulp.com/blog > >>> Talend Community Coder - http://coders.talend.com > >> > >> -- > >> Daniel Kulp > >> dk...@apache.org - http://dankulp.com/blog > >> Talend Community Coder - http://coders.talend.com > >> > >> > > -- Matt Sicker <boa...@gmail.com>