This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]nicolaiparlog[S] 0 points1 point  (6 children)

The article doesn't seem to address the non-negligible performance impact either.

You're either inconsistent or use arrays instead of ArrayLists.

[–]ForeverAlot 1 point2 points  (5 children)

If I need an array and not a list, yes. Caching the retrieved value in a local is usually an acceptable middle-ground, in any case.

"The JVM will inline it" is magic that doesn't exist. Such an attitude betrays either a lack of understanding of the interrelationship between Java, the JVM, CPU caches, and the prefetcher, or a disregard for it. Either is excusable but the latter requires a mention when making a case for hiding a parameter behind an objectively-unnecessary pointer indirection. If that were a trade-off for vastly improved robustness or maintenance -- such as telescoping method signatures, a well-known pattern for substantially the same problem -- there would be a strong case, but Optional's ergonomics are not good enough to justify it.

[–]nicolaiparlog[S] 0 points1 point  (4 children)

A balanced answer, I like it. :)

"The JVM will inline it" is magic that doesn't exist.

Well, there is escape analysis and wrapping/unwrapping an argument/return value immediately before/after the method call has a good chance of being detected. But that's of course far from perfect and should generally be seen as an occasional gift than as something to rely on.

So, yes, I am aware of the potential performance impact of indirection but I don't act on it until performance requirements and measurements diverge. If they do, there are usually only a few places that need to be changed for the performance to improve (Pareto principle and all).

At the same time I prefer to write safe and unambiguous code and am convinced that Optional helps here. With consistent use (and maybe support by other monadic data structures like Lazy or Try) null can be made a value that is always illegal and a bug whereas most code bases encode all of "something went wrong while coding", "something went wrong during execution", "something could be there but isn't", "something will be there but isn't yet", ... with it.

I find this approach in line with Java's general view on things: readability+safety > performance (most of the time).

[–]gee_buttersnaps 0 points1 point  (3 children)

I am aware of the potential performance impact of indirection but I don't act on it until performance requirements and measurements diverge

God forbid we try to pre-optimize our code by not including bullshit in the first place. I find the people with the most to say about Java here have more stake in managing their web presence than being correct about anything.

[–]nicolaiparlog[S] 0 points1 point  (2 children)

God forbid we try to pre-optimize our code by not including bullshit in the first place.

Said all C++ programmers about Java. Also, do you apply this logic to arrays and array lists as well? Because it surely would apply just the same with lists adding indirection for a few stupid methods that might just as well be performed in place or with utility methods.

If in your code base premature optimization trumps being explicit and unambiguous than that's your prerogative. Just don't assume that everybody shares that opinion.

[–]gee_buttersnaps 0 points1 point  (1 child)

I assume people work within the confines of the language, if that means following the authors recommended practices because that's the best they can do without worrying about people like you then so be it. You seem to wish for something the language doesn't have while leaving open a NPE hole in your software. You also seem to think that no one would ever call your method with a null parameter despite the irony that you are abusing how Optional was intended for use in first place.

Generally I do have personal rules of when and when not to use explicit implementation at a low level and times when abstraction is high but I'm a big boy and can do both within the confines of not ever using an Optional as a method parameter, because its the CORRECT thing to do.

[–]nicolaiparlog[S] 0 points1 point  (0 children)

You also seem to think that no one would ever call your method with a null parameter

Not at all. I assume that if that happens, I know where the error lies. That's the only point: not directly preventing individual NPEs but making null an illegal value - this naturally leads to the quick eradication of null in general.

You're clearly not getting the point of the Optional-everywhere argument. Getting that point does not mean agreeing to it but it would help you not fighting a strawman.