RFR 8135248: Add utility methods to check indexes and ranges

[Paul Sandoz]

> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> Just to note that an ideal location for this would be on a new class,
> one that has been discussed before, an "argument checker class".
> 
> See Guava Preconditions:
> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java
> 
> See Commons Lang Validate:
> https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html
> 
> See OpenGamma ArgChecker:
> http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html
> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java
> 
> This was discussed when Objects.requiresNotNull was discussed IIRC.

FTR here is the discussion:

http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date>

AFAICT there was no objection in principle to such classes. I sense that the objection to going that route was due to an increase in scope and as such it would overrun it's budget.


> I
> still think it would be a great addition to the JDK (as every project
> has something similar). This issue could be the start, although it
> would need a few more methods, guided by the examples above.
> 

Just a few *more* bike sheds to paint :-) I am concerned i will never finish this nor other un/related tasks.

For now I am ok with Objects being that "argument checker class” simply because it already has a gravitational pull due to the mass of the existing check methods [*].

Paul.

[*] I believe it is a backwards compatible to change Objects to extends from Preconditions and move the existing static check methods to Preconditions. That seems like a sleazy trick though.