Java 7 : The new java.util.Objects class | Hacker News Reader

Java 7 : The new java.util.Objects class

baptiste-wicht.com

38 pointsnoarchy33 comments

I 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.

Aren't these just one line utility methods that a user could write themselves?

Yes 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.

One 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")){...}

"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.

And 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.

What are the odds again that we'll ever see widespread adoption of Java 7?

The 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.

Also, Java 7 will have native support for dynamic typing.

Java 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.

Actually, the current status is that Java 7 will have closures.

Have we even seen widespread adoption of Java 6 yet?

Um... about 100%?

Why 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.

April fools?

Oh no... it's Java.

I 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.

I 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".

The 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?

The 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.

why is this a monstrosity?

It'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.

You 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.

I'm not stuck with them, I just use Haskell.

Just because Java is popular doesn't mean you have to use it.

Examining 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.

But we're not talking about advancing language design--we're talking about a small modification to an existing, widely used language whose basics are not going to change. There are a lot of problems with Java I'd like to see fixed before null, and the Java community has dismissed most of those as too radical (like closures).

There are languages which work (mostly) without nulls on the JVM though. Scala does something very similar to Haskell's Maybe. (Although for interoperability with Java it can deal with nulls if you insist.)

The power of Maybe in Haskell comes from both the existence of the type, and from the existence of sequencing combinators that understand how to handle Maybe.

Just adding a Maybe type to Java wouldn't do anything; each method would still have to handle the Nothing case in some way.

For Maybe to be useful in Java, control flow would have to change from running one line after another to "running" by applying functions, so that whether or not to run each "line of code" would be determined by a combinator that understands the semantics of Maybe. Then, of course, you just have Haskell, which already exists!

A better option for Java would be a type that could not be null. I don't think the language allows the compiler to determine this, though, which means it probably won't exist (or if it does exist, it won't be too useful).

Basically, if you want a good type system, you want to ditch Java.

Over 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.

12 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.

Where 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.

These 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.

These 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.

Java 8?

It seems like isBlank() would mean null or empty or all whitespace?

Reply on news.ycombinator.com