RFR 8135248: Add utility methods to check indexes and ranges

[joe darcy]

On 9/29/2015 2:28 PM, Stephen Colebourne wrote:
> On 29 September 2015 at 21:01, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> The concern i have is once Preconditions is let loose the scope expands with proposals for “just one more method” (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I don’t want to discuss such additional methods right now otherwise i will never make progress with the current set.
>>
>> A way forward is to initially include Preconditions with *only* the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects.
> As you say, there is lots to discuss:
> - the class name
> - any IllegalStateException methods? Or two classes, one for args and
> one for state?
> - design for static import or not
> - message formatting
> - complete messages, or ones where only the argument name is specified
> - nonNull() vs notNull()
> - IllegalArgException vs NPE for notNull
>
> The first three points are key and set the tone of the class, As such,
> it is hard to just create it. (For example Guava Preconditions is
> stylistically different to Commons Validate or OpenGamma ArgChecker)
>
> If you need to move on, then add the methods to Objects, and see if
> separately agreement can be got on a new class, potentially moving the
> methods before 9 is released.

Yes, my preference would be to push the methods first to 
java.util.Objects and then move them to a checker / validator class if 
such a utility class is added to the JDK later in JDK 9.

-Joe