Have to agree here. The article's use of Optional is well intentioned, but shows use of the construct in a way that it was not intended. It should be used minimally, and only as a return value to signify the absence of a value. When you notice that Optional is not serializable, this starts to sink in.

Here are some more thorough treatments: http://stackoverflow.com/a/23464794 http://blog.jhades.org/java-8-how-to-use-optional/

Watching the evolution of languages / APIs makes me believe that Optional over-use is a necessary step between "our language has no formal Optional therefore crash" and "our language uses null in a sane manner".

C#'s prior behavior gives me hope for languages I'm currently paid to care about like Java and Swift on this issue.

When I get some time I'll update the OGMJ. I think the choice of tools mentioned is still very much up-to-date, it's just that some of the APIs used in the examples have been upgraded.

I really like OGMJ, it's definitely a great resource and I recommend it to many new Java developers; however, I disagree re: tools mentioned.

After trying dropwizard for a few projects, the superiority of the spring-boot and its various ecosystems just blew me away.

Also, while I appreciated Gradle, Maven is just much more supported through the entire eco-system. As a new comer to Java from C++/Python, it made a big difference.

You're probably right about Spring Boot. I've never been a web developer, and TBH, I've had no direct experience with either Boot or DW other than a simple Hello, World. At the time DW seemed the safer choice simply because it used the JAX-RS standards, and using standards in the Java world (especially good ones like JAX-RS) is a very good idea. But in the meantime Spring Boot has also done the right thing and adopted JAX-RS (at least as an alternate API), so I should add it to the post.

As to Maven vs. Gradle, that turned out to be the most controversial point of the entire guide -- which surprised me. Let me put it this way: both are good and I prefer Gradle. Also, Gradle, while still far behind Maven in terms of adoption, has good momentum. Either is a good choice at this moment, but I would guess that Gradle will take the lead in five years (although it's far from a safe bet).

5 years is a long time in IT. Gradle has a millstone called "Groovy" around its neck because of an early poor choice to ship with only one configuration language. Maybe they'll enable more languages to be plugged in later on, but there's an ex-Pivotal programmer who used to work on Groovy now working at Gradleware on Gradle who might sabotage such an effort because of his lingering association with Groovy.

> Maven is just much more supported through the entire eco-system

Could you give some examples? I haven't had much problem with Gradle support, and Gradle's essential advantages over Maven fat outweigh what little I have had.

Keep in mind that Tony Hoare, the inventor of the null pointer, calls this invention his billion dollar mistake. I generally think that he is right and use of null should almost always be avoided.

By all means, have more clumsy, less straightforward ways to represent the lack of a value in your code, because Tony Hoare says so.

An Optional type is more clumsy than null checks and null returns sprinkled everywhere??

The problem with NULL is that it can be there for literally any reference in your code. So, unless you are careful, you can get an NPE when calling any single object method. In languages without NULL this can never happen making them much easier to reason about.

My initial reaction: programming ain't bean bag. Them's the breaks.

Then I think of it and I see the real problem is languages making all nonprimitive types into pointers without being explicit. In a language like C it's more obvious what can be null.

If null can be problematic then certainly making it more obvious when you might have a null is a pretty good idea. I tend to think, however, that getting rid of null completely as a concept is even better. One less thing to worry about.

A NullPointerException is unchecked as well. I would say about 40% of our code is checking for null to avoid NPEs especially with APIs. You have to protect yourself and cannot take nothing for granted.

Despite what he says, I don't think Hoare actually invented the "null pointer", as address 0 for "not exists" or "end of list" was probably a common convention ever since linked structures existed and independently discovered by many others. (The other convention would be the all-bits-1 value, but I'd assume that testing for 0 was easier and thus more widely adopted. Also, "0 = nothing" makes great sense.)

IMHO Optional just feels like another typical Java dogmatic overabstractionism. "Null pointer exception? So what? Just catch it." Then again, I mostly use C/Asm.

Given that the Option type has existed in programming languages other than Java for decades I don't think it makes sense to call it a "typical Java" thing.

I can see how a C/Asm programmer wouldn't like it though. Very different mindsets. :)

The difference is that other languages which originally had the Option type don't have null, so it's the only option. I meant it's typical of Java to take features from other languages, resulting multiple slightly-different-but-incompatible ways to achieve the same thing.

I certainly agree that Java would be a much better language if NULL could be eliminated completely. Backwards compatibility though...

sigh

Yeah, Optionals came from other languages, not originally Java.

IMO the problem with Optionals is that they'll never suffice unless they are part of the language itself, like in Swift. As this article pointed out, Optionals aren't supported in any existing APIs, so you still have to do a ton of null-checking everywhere. And there is nothing that guarantees an Optional reference itself can't be null, which is why you really want language-level support.

I'm probably being a bit too pedantic here, but strictly speaking they don't need to be part of the language at all. You just need basic support for (generic/parametric) algebraic data types.

For example, Haskell has Maybe which is not part of the language nor treated specially by the compiler in any way. It is part of the Prelude (think "standard library"), so that (basically) all libraries can agree on what "Maybe a" means.

In other paradigms (Lisps) null is a lot less than a billion dollar mistake, it seems it goes better with map/filter/fmap patterns. In imperative languages, data is tied to control, and null means segfault.

When some ELisp code crashes in my emacs with an error like:

  error: (stringp nil): not a string

I think it indicates Lisps suffer from this problem too...

It does, I said 'a lot less' not 'zero dollar mistake'. Recursively defined lists take care about nil, and since it's one of the most used ways to program in lisp it makes a lot of logic nullproof.

I'm also not a fan of passing Optionals into methods. Most of the time it's easier and cleaner just to write an additional method without that optional parameter.

It can grow cartesian though.

I think the best compromise is to declare a new data type for the argument, such as:

  data ExecutionDirectory = ExecuteInCWD | ExecuteInDir FilePath

And take an ExecutionDirectory instead of a `Maybe FilePath`.

Of course, you need light-weight data declarations for that.

I'm curious, which aspects of An Opinionated Guide to Modern Java have dated?