Hi Sandeep - This is a good point and I should try and set expectations here properly. I think that it would be good practice to be careful about where we add Java 8 specifics.
I would propose that we should limit this use to new features. This will help minimize the pain in backports to previous releases that community members need to continue to support. I would not like to see changes across the codebase to start using things just because we can. It will take some thought sometimes to limit it to new features and we won't catch them all. But the flip side of that is we won't break everyone with a single change if we don't do it against many files at once that don't need it. That's my thoughts on it anyway... thanks, --larry On Mon, Sep 18, 2017 at 11:15 AM, Sandeep More <[email protected]> wrote: > +1 as well. Also, we should be able to leverage some functionality from > JDK8 without the fear of breaking builds. > > Best, > Sandeep > > On Mon, Sep 18, 2017 at 10:48 AM, Philip Zampino <[email protected] > > wrote: > >> +1 >> >> -- >> Phil >> >> >> On 9/18/17, 10:38 AM, "larry mccay" <[email protected]> wrote: >> >> All - >> >> We have been supporting Java 7 long past it's EOL which was in 2015 in >> order to be compatible with deployments that are conservative in >> upgrading >> to Java 8. >> >> I feel that at this point anyone that has not upgraded is not >> sufficiently >> concerned about the security implications and that this is no longer >> being >> conservative. :) >> >> In addition, a number of components within the hadoop ecosystem have >> already dropped Java 7 support. The popularity of these particular >> components more or less means that Java 8 will likely be in place >> anyway. >> >> This will also enable us to upgrade to the pac4j 2.x releases which >> have >> features that we would benefit from. >> >> If anyone has any concerns about this - please feel free to raise a >> flag. >> >> thanks, >> >> --larry >> >> >> >
