specialist on Deprecating: java.util.Optional.get()?

Comment on Deprecating: java.util.Optional.get()?

I will never use Java's Optional. I'm baffled why it even exists. Further, I remain unclear on the value (haha) of the @Nullable and @NotNull annotations. If it's not baked into the language, why bother?

I've been using NullObject since (checking...) 1996. This is The Correct Answer.

http://c2.com/cgi/wiki?NullObject

I first read about NullObject here:

Object-Oriented Design Heuristics http://amzn.to/1ND1YSU

What'd be really neat is some mojo to remove the boilerplate of implementing NullObjects.

lmm 10y

Optional is like a generic NullObject. What should e.g. Map#get return, if not Optional?

specialist 10y

Java's Optional is exactly unlike a NullObject. Optional is not a Proxy. Being untyped, not being an implementation of the interface, it can't be used interchangeably.

It's NullObjects all the way down. Makes more sense when designs favor compositions over inheritance.

Optional is the wrapper no one needed. For syntactic sugar, static library methods worked just fine.

dangerlibrary 10y

Am I missing something? Optional<String> can't contain an integer - it's either empty or contains a String. It certainly looks typed from where I sit.

lmm 10y

So once again, if you didn't have Optional, what should Map#get return?

specialist 10y

Really?

  class Widget {...}

  class final NullWidget extends Widget {
    static NULL_WIDGET = new NullWidget();
    ...
  }

  class WidgetMap extends HashMap<String,Widget> {
    Widget get( String key ) { 
      if( contains( key )) { return super.get( key ); }
      return NULL_WIDGET;
    }
    ...
  }

lmm 10y

Urgh. Sure that's one option, but I don't want to have to subclass HashMap every time I want to store something different in it. Also sometimes I want generic code that uses a map.

cytzol 10y

And sometimes you want a different type of map...

pron 10y

I remain unclear on the value (haha) of the @Nullable and @NotNull annotations. If it's not baked into the language, why bother?

What's the difference between "baked into the language" and a language with built-in support (added in Java 8) for pluggable, inferrable type systems (of which @NotNull is just one, pretty basic, example)?

specialist 10y

In principle and practice, I oppose all use of annotations. It's metaprogramming (aka magic).

Being the new COBOL, Java is best when it just works. Anyone who can use annotations responsibly will be happier choosing a grown up language like Clojure.

In truth, I don't have an answer for why method?method?property syntax is better than using annotations. Because I tend to use NullObjects and avoid method chaining, to me it's a false choice.

Edit: Concision.

pron 10y

I oppose all use of annotations. It's metaprogramming (aka magic).

Don't conflate annotations (a compile time construct) with how they can be used. They can be used in many ways. When used as runtime metadata they can be "magic". But @Nullable/@NonNull is (or rather, can be used as) one of Java 8's pluggable type systems, inferred and and checked at compile time[1].

[1]: http://types.cs.washington.edu/checker-framework/current/che...

Comments