Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
On Wed, Oct 14, 2009 at 3:38 AM, Stephen Colebourne scolebou...@joda.orgwrote: While I agree that the nonNull methods below are useful and should be in the JDK, I question whether they should be on j.u.Objects. I believe that there is a whole category of methods to pre-validate the arguments of a method, such as Commons Lang Validate, or Google Prevalidate. [s/Prevalidate/Preconditions/] I'm in complete agreement, of course. In Google, checkNotNull() is certainly the most popular of our Preconditions methods, but checkArgument() is fully half as popular, and checkState() half in turn (meaning it's still used thousands upon thousands of times). We also have similar methods to throw IndexOutOfBoundsExceptions when appropriate, which are not needed nearly as frequently, but are a real relief to use when you do need them (many JDK methods could make use of them, especially since Martin has just finished optimizing the heck out of them for our next RC (1.0-rc4)). checkArgument() and checkState() don't let developers do anything they can't already do with if/throw, but I very strongly believe we have significantly more of our codebase doing proper precondition checking because of this small amount of paving we applied to that path. Just some more input to consider. http://commons.apache.org/lang/apidocs/org/apache/commons/lang/Validate.html http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/base/Preconditions.html -- Kevin Bourrillion @ Google internal: http://go/javalibraries external: guava-libraries.googlecode.com
RE: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
I agree with Stephen. There are a slew of validation methods that would be beneficial, and if you really want to drive the JDK towards standard validation, refactor them out into a Validation class. Look at what Spring has written for themselves: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/ut il/Assert.html Paul Fully agree with you both, Stephan and Paul. A Validation class with a broad perspective makes much more sense to me. --Jesus
Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
Jesús Viñuales wrote: I agree with Stephen. There are a slew of validation methods that would be beneficial, and if you really want to drive the JDK towards standard validation, refactor them out into a Validation class. Look at what Spring has written for themselves: http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/ut il/Assert.html Paul Fully agree with you both, Stephan and Paul. A Validation class with a broad perspective makes much more sense to me. --Jesus If such a validation class is added to the platform, the nonNull methods can be moved there. Until then, they can live in Objects. -Joe
Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
Joseph D. Darcy wrote: If such a validation class is added to the platform, the nonNull methods can be moved there. Until then, they can live in Objects. At first glance, such an approach makes perfect sense. However, we should really stop and question whether it is right or not. One point that has been made about Java over recent times is that it lacks a clear direction. A number of small changes are being added (Project Coin and here) which don't necessarily have a cohesive goal. To my eye it seems that one reason for these getting the go-ahead is that they are suposedly low-risk and low-issue. Each individual change seems small and relatively minor that sometimes its tempting to think that they can cause no harm. Yet even with these seemingly simple changes we find that the lack of a clear vision for Java kicks in and causes trouble. I mention Coin here, because there have been real debates there on various features (including diamond type inference, ARM and map literals vs pair literals) and their proposed implementation. The question is whether the choices made *now* will hinder future evolution of the Java language. Because we (the Java community, and, I strongly suspect, Sun) have no clear view of where Java is going, it becomes impossible to judge whether those choices are the right ones or not. In this specific case, again we have a case where a change *now* may hinder the future evolution of the JDK libraries. If we add nonNull to Objects, then it will be in the wrong place and confusing if we then add a Validate class in JDK8. Or we all have to accept duplication. More broadly, and looking at this discussion overall and Joe's responses, I read between the lines that Joe only has approval to add a single class Objects, and no other classes (such as Hasher, Joiner, Strings, Validate, and many others we might find useful). Because the remit is so narrow, we don't get to properly examine more broadly what additions are needed to the core libraries. As such, it feels like the decisions taken here and now have the potential to be remarkably hit and miss. Stephen
Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
Stephen, My interpretation of Joe's email was that it would stay in j.u.Objects unless someone (other than him) contributes the Validate class and tests. Granting your point, his choice would otherwise stand and re-factoring it after JDK 7 would be impossible. I am interested in such a class and will try submit my first patch for JDK. Do you want to help? I am open to doing it together. Paul
Re: nonNull and similar methods [was Re: First round of java.util.Objects for code review (bug 6797535)]
Stephen Colebourne wrote: Joseph D. Darcy wrote: If such a validation class is added to the platform, the nonNull methods can be moved there. Until then, they can live in Objects. At first glance, such an approach makes perfect sense. However, we should really stop and question whether it is right or not. One point that has been made about Java over recent times is that it lacks a clear direction. A number of small changes are being added (Project Coin and here) which don't necessarily have a cohesive goal. To my eye it seems that one reason for these getting the go-ahead is that they are suposedly low-risk and low-issue. Each individual change seems small and relatively minor that sometimes its tempting to think that they can cause no harm. Yet even with these seemingly simple changes we find that the lack of a clear vision for Java kicks in and causes trouble. I mention Coin here, because there have been real debates there on There have more often been long exchanges dominated by heat rather than light, but that is not unique to the Coin list. [snip] More broadly, and looking at this discussion overall and Joe's responses, I read between the lines that Joe only has approval to add a single class Objects, and no other classes (such as Hasher, Joiner, Strings, Validate, and many others we might find useful). My side project here is defining java.util.Objects. It is not defining Hasher, Joiner, Splitter, Validator, or any other possibly useful class. Anyone else is free to send in proposals, implementations, and tests for such facilities and someone might offer to sponsor such proposals through the currently Sun-internal processes to get API changes in JDK 7, as I've recently offered to do for String.join. -Joe
