RFR 8135248: Add utility methods to check indexes and ranges

[Peter Levart]

On 09/29/2015 06:05 PM, Paul Sandoz wrote:
>> 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.

Yes, but the same could be achieved by just re-implementing those 3 
methods in Preconditions or delegating from Preconditions to Objects - 
without strange subtyping.

I think it's worth introducing Preconditions class. checkNotNull 
overloads are equally well suited for Objects as they are for 
Preconditions, so it's not wrong to have them in both, while checkIndex 
and friends don't really suit any of the existing classes. If I would 
have to search for them in among existing classes, Arrays would be the 
place to look first. List interface the 2nd. IndexOutOfBoundsException 
wouldn't come to my mind, as Exception(s) are usually not homes for 
logic, neither would Integer which is to abstract to mentally associate 
it with array or list index checks.

Regards, Peter