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 :) 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.
