4 ms·
Aren't these just one line utility methods that a user could write themselves?
by gfunk911 17y ago
Aren't these just one line utility methods that a user could write themselves?
- brown9-2 17y agoYes and there are a number of libraries (commons-lang, Spring, etc.) which include Assert classes for things like Assert.notNull(), Assert.notEmpty(Collection<T>), etc. This seems like recognition that such commonly used library functionality might also be useful to be in the base API. Though I would think it would make more sense for Objects.nonNull() to throw IllegalArgumentException, not a NPE.
- ShabbyDoo 17y agoOne could make the "Aren't these just libraries?" argument for the collections stuff introduced in 1.2, but this standardization served a legitimate purpose by facilitating rich inter-component/framework interoperability. While I don't dispute the benefits of using this new Objects class, provides methods used in implementations, not common API representations. So, I'd argue that the Java ecosystem isn't much better off for it. This isn't to say that I'm not happy that it's there, but I don't think it's nearly as noteworthy as new language features, underlying JVM performance improvements, etc. As an aside, I was surprised that the article did not take advantage of static imports to rid the code of the "Objects" references. One could just say: if (notNull(foo).equals("bar")){...}
- jimbokun 17y ago"As an aside, I was surprised that the article did not take advantage of static imports..." I also much prefer the readability of static imports, but it won't work for the "equals," "toString" and "hashCode" methods, obviously.
- bobbyi 17y agoAnd then everyone who ever reads your code has to look up your versions of the utility methods to make sure they are implemented the way one expects.