commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: [lang]
Date Tue, 02 May 2017 00:25:53 GMT
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" <garydgregory@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message