> On May 1, 2017, at 8:25 PM, Stian Soiland-Reyes <st...@apache.org> wrote: > > Adding a class with a plan to @deprecate it, something doesn't sound right. > :) > > We should not be putting much effort (and future maintainability) into > adding functionality in Lang that jdk8 already (easily) can do. The point > of Lang is to complement JDK's Lang classes and friends, not to backport > what the current JDK has already added. > > (Obviously existing Lang functionality is or will be superseded by new JDK > additions, that just shows that the philosophy of Lang is right.) > > If you are stuck in jdk7 you are often also stuck with older Commons Lang. > (Oversimplification, yes) > > We have java7 as target (I'm positive to bump it to 8) - but primarily for > backwards compatibility as Lang is ubiquitous and it makes sense to stay > one behind. But we don't need to add *new* backwards compatibility :)
Curious. This sounds like an argument for major versioning Lang in step with java, which seems natural. > > We could make excemptions and do backports, but then I think that should be > for more core JDK8 improvements like Optional. > > That said, your implementation is straightforward​, useful, and unlikely to > cause trouble; I would not veto your commit if it goes forward ;) > > > On 1 May 2017 9:40 pm, "Gary Gregory" <garydgreg...@gmail.com> wrote: > > In my mind, we target a given platform, in this case its Java 7. So the > proposal is valid IMO. Then when switch to Java 8, we can mark the class as > deprecated and remove it in 4.0. I'm not hard set on including this > specific class, it's just something I use. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
