> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebou...@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.
