7 ms·
Java 7 : The new java.util.Objects class
- gfunk911 17y agoAren'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.
- WilliamLP 17y agoWhat are the odds again that we'll ever see widespread adoption of Java 7?
- zmmmmm 17y agoThe JVM is going to spread quickly as it will (or at least, should) offer performance advantages for the many various dynamic languages that run on it. As for Java7 - it will be slower to spread but I think the addition of closures will be decisive in garnering developer support for it as a wealth of new APIs (or reworking of old ones) will quickly appear that will have everyone wanting to upgrade. So it will happen for most server side code within a couple of years I would expect.
- Spreadsheet 17y agoAlso, Java 7 will have native support for dynamic typing.
- seunosewa 17y agoJava 7 doesn't have closures. Personally, I just want a better syntax for instantiating anonymous classes. I find that ful closures aren't really necessary.
- brazzy 17y agoActually, the current status is that Java 7 will have closures.
- j_baker 17y agoHave we even seen widespread adoption of Java 6 yet?
- brazzy 17y agoUm... about 100%?
- bensummers 17y agoThe date on the article is April 2nd. I did check. Is the inclusion of this monstrosity in a standard library more evidence that null references are a misfeature? A explicit construction like Maybe<T> seems so much of a better idea.
- brown9-2 17y agowhy is this a monstrosity?
- bensummers 17y agoIt's a monstrosity because the underlying language design makes it necessary. A whole class of bugs could be eliminated if the language didn't allow you to have null references, and instead, made you explicitly state your function might not return an object, for example, the Maybe datatype in Haskell.
- samdk 17y agoYou can argue that null references are problematic and I'll agree with you. But they're a part of Java (and a whole host of other languages, too) and that's not going to change anytime soon. Saying that this is "a monstrosity" because nulls shouldn't exist in the first place is completely unhelpful. Whether we like them or not, we're going to be stuck with them for a long while, and attempts to make them less painful to deal with aren't a bad thing.
- jrockway 17y agoI'm not stuck with them, I just use Haskell. Just because Java is popular doesn't mean you have to use it.
- bensummers 17y agoExamining existing languages is useful to advance the art in computer language design. Being "stuck with them" just means we have the experience of writing software with these features. In addition, there's no reason we can't write a language without nulls which works on the JVM.
- chipsy 17y agoI was actually just thinking recently about eliminating unchecked null errors in my haXe code, went looking through the features and discussions, and came up with two "today" solutions and one "proposed for the future". In light of how little Java seems to be doing to eliminate those errors, maybe they will interest: -Right now it's possible to use the haXe Enum to implement a form of "Maybe" type: calling some "get" function returns the Maybe, and then you do a switch statement on it. From there the compiler forces you to cover all cases. Caveat: Enum is quite a slow feature. -I can force the "get" function to pass in handling code for null and non-null cases as arguments. Caveat: Requires the handlers to be full functions, not just expressions, which is bulky and inflexible. This should be doable in Java too, but without inference, you might have to fight the type system more to get it right. -Macros are proposed: Then I can turn my "get" function into a "get" macro that forces me to always provide the null handler. Caveat: It's a bit more involved than a Maybe type, which would do the compile checks automatically. Overall, I'm really happy with where haXe is going. It's growing some really useful features while remaining a cross-target language. If macros get in(hotly anticipated, but probably not soon) it'll be a very exciting time for the language.
- jrockway 17y agoApril fools? Oh no... it's Java.
- m0th87 17y agoI don't see how it could be interpreted as a joke. I've given up Java because of its verbosity, but anything that reduces it is a win.
- jrockway 17y agoI chuckled at the function that takes an object as an argument and returns the same object as the result. Yes, I know it throws an exception if it's null... but when your id function has side effects, it's a sign that your language is Just "not that great".
- blueag 17y agoCan you give some examples of how other languages handle null?
- jganetsk 17y agoThe id function in Java has no side effects... public <T> T id(T t) { return t; } That's an id function. It works fine with nulls. Where did anyone say that java.util.Objects was providing an id function anyway?
- GrandMasterBirt 17y ago12 years in the making. In Java 8: java.util.Strings.isBlank(string) -- returns true if the string is null or "", else returns false. Its wishful thinking hoping for this in Java 7... So I'll just lower some standards.
- arethuza 17y agoWhere do you get 12 from - I've used Java from early in '95 so I'd make it at least 15. Can't stand it these days.
- jcromartie 17y agoThese days I just treat Java like C. It has a relatively small syntax and small feature set, but it has a relatively large set of libraries available (built in and otherwise). The language itself just isn't that interesting. It's what people are building with it (like Clojure, or Scala, or Hadoop, or Processing) that are interesting.
- mahmud 17y agoThese days? Steele's "The Java Programming Language" is where I learned Java first, and I don't think I have read another book, spec, or library documentation for java after that. Java as "C with OOP, Unicode, Exception handling and Threads" is really an excellent language. I write one small java app every 4 years and that subset of it served me well.
- Spreadsheet 17y agoJava 8?
- skybrian 17y agoIt seems like isBlank() would mean null or empty or all whitespace?
- JulianMorrison 17y agoWhy not fix Java to have compile-time checked not-null types? Given that not-null is a strict subset of nullable, it wouldn't break code to annotate the standard library with not-nulls. Then we can avoid these run-time checks entirely. Oh and while you're about it, please re-parent InterruptedException onto RuntimeException, and make Object's default toString method use reflection to print the contents of all fields in a readable format with recursive toString calls.
- deleted 17y ago[deleted]
- heresy 17y agoOver in C#, the implementers decided to give us extension methods so we could inflict this terror on ourselves in a relatively nice way, and left it out of the standard library.