7 ms·

"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agr

"If you're using Java 8, you can use the excellent new Optional type. If a value may or may not be present, wrap it in an Optional class like this" While I agree with most things, overuse of Optional like this is an antipattern IMO. Having done a lot of Java 8 development, I find Optional is best for return types, but otherwise forcing callers to wrap values in Optional is unnecessary as opposed to something like Scala. Those that work on the JDK feel the same [1][2] and I think [2] is even overuse with the prevalence of static analysis tools and @Nullable. Although a tad dated, I find [3] to be a good guide to modern Java all around. 1 - http://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 http://stackoverflow.com/questions/26327957/should-java-8-ge... 2 - http://blog.joda.org/2015/08/java-se-8-optional-pragmatic-approach.html http://blog.joda.org/2015/08/java-se-8-optional-pragmatic-ap... 3 - http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/

yrro 11y ago
I'm curious, which aspects of An Opinionated Guide to Modern Java have dated?
kilink 11y ago
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.
- Peaker 11y ago
  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.
harryh 11y ago
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.
- agumonkey 11y ago
  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.
  - Peaker 11y ago
    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...
    - agumonkey 11y ago
      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.
- userbinator 11y ago
  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.
  - harryh 11y ago
    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. :)
    - 11y ago
tl 11y ago
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.
rbolkey 11y ago
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://stackoverflow.com/a/23464794 http://blog.jhades.org/java-8-how-to-use-optional/ http://blog.jhades.org/java-8-how-to-use-optional/
pron 11y ago
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.
- mahmoudimus 11y ago
  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.
  - pron 11y ago
    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).
    - vorg 11y ago
      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.

yrro 11y ago

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

kilink 11y ago

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.

Peaker 11y ago
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.

harryh 11y ago

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.

agumonkey 11y ago
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.
- Peaker 11y ago
  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...
  - agumonkey 11y ago
    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.
userbinator 11y ago
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.
- harryh 11y ago
  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. :)
  - 11y ago

tl 11y ago

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.

rbolkey 11y ago

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://stackoverflow.com/a/23464794 http://blog.jhades.org/java-8-how-to-use-optional/ http://blog.jhades.org/java-8-how-to-use-optional/

pron 11y ago

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.

mahmoudimus 11y ago
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.
- pron 11y ago
  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).
  - vorg 11y ago
    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.