tag:blogger.com,1999:blog-741750605858169835.post8127900411456099448..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Optional in Java SE 8Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-741750605858169835.post-76794490327862314572021-02-16T18:48:00.677+00:002021-02-16T18:48:00.677+00:00@carlo There is a huge difference between your two...@carlo There is a huge difference between your two examples. In the first example I am passed an Optional so I explicitly know it could be empty. In the second example I am passed a String and I have no idea if it is nullable or not.Sarah Ichinumihttps://www.blogger.com/profile/02470829421295617931noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-14443269148495201222020-09-23T10:51:46.856+01:002020-09-23T10:51:46.856+01:00We don't gain anything if we define Optional a...We don't gain anything if we define Optional as an attribute. in the end, you always need to check if it is present or not:<br />public String getGreeting(Optional param) {<br /> if (param == null || !param.isPresent()) {<br /> return "Hello World";<br /> } else {<br /> return "Hello " + param;<br /> }<br />}<br /><br />public String getGreeting(String param) {<br /> if (param == null) {<br /> return "Hello World";<br /> } else {<br /> return "Hello " + param;<br /> }<br />}<br />carlohttps://www.blogger.com/profile/10407917112484109180noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-71988327015900627482016-08-08T15:06:43.250+01:002016-08-08T15:06:43.250+01:00Very Nice Article! Thanks for sharing your thought...Very Nice Article! Thanks for sharing your thoughts!Janahttps://www.blogger.com/profile/18369804685747422667noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49621890847796728722015-10-13T14:47:10.136+01:002015-10-13T14:47:10.136+01:00If you're going to check if a value is present...If you're going to check if a value is present, you could just not use Optional and make a null check. Optionals don't feel right as method arguments.Juan Pablo Angamarcahttps://www.blogger.com/profile/05690702054169764220noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20420852481946316412015-10-12T21:21:58.356+01:002015-10-12T21:21:58.356+01:00New enterprise code does not.New enterprise code does not.Juan Pablo Angamarcahttps://www.blogger.com/profile/05690702054169764220noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-20363323694892778202015-10-12T21:19:35.545+01:002015-10-12T21:19:35.545+01:00No. You should be using Optional#ifPresent, Option...No. You should be using Optional#ifPresent, Optional#flatMap, Optional#map or Optional#orElse*. Using #isEmpty and #get defeat the purpose of using Optional, because it isn't better than making the old fashioned comparisons against null!Juan Pablo Angamarcahttps://www.blogger.com/profile/05690702054169764220noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-57256292317115331732015-10-12T06:58:58.464+01:002015-10-12T06:58:58.464+01:00We used java8 currently and followed an approach o...We used java8 currently and followed an approach of using Optional where null could be returned, and do a check of Optional.isEmpty() before doing an Optional.get(). This helped us to make code consistent and rescuing developers from adding null checks . Anonymoushttps://www.blogger.com/profile/01542749940919156498noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-19153841632455969022015-10-08T15:36:29.396+01:002015-10-08T15:36:29.396+01:00Totally agree.Totally agree.Anonymoushttps://www.blogger.com/profile/16239924483801440003noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42488010154985089482015-08-04T13:46:06.576+01:002015-08-04T13:46:06.576+01:00@Juan Pablo Angamarca this is my point, if the par...@Juan Pablo Angamarca this is my point, if the parameter is of type "optional", the function code is forced to check the value. By other hand the caller knows that the parameter is not mandatory.Filippo De Lucahttps://www.blogger.com/profile/08818361807047914938noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-48045368153350499382015-08-02T15:02:15.419+01:002015-08-02T15:02:15.419+01:00Or it would be better if it handled null like obje...Or it would be better if it handled null like objective-c, basically message to nil is no-op that returns nil.<br /><br />If you are using stream, then you might be forced to use it, but outside that I think it looks ugly. <br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-74752402716473509942015-06-08T16:09:39.123+01:002015-06-08T16:09:39.123+01:00Filippo De Luca, "optional" arguments sh...Filippo De Luca, "optional" arguments should be seen with suspicion. They may lead to NPEs, or worse, unintended default behavior. That's why the JSR 310 API, while inspired by JodaTime, does not accept nulls as method arguments.Juan Pablo Angamarcahttps://www.blogger.com/profile/05690702054169764220noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-45726300043503518642014-12-03T20:52:21.221+00:002014-12-03T20:52:21.221+00:00The point is that the signature of the method expl...The point is that the signature of the method explicitly exposes that argument as not strictly needed (Optional in fact).Filippo De Lucahttps://www.blogger.com/profile/08818361807047914938noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-15043797972460795912014-12-01T23:12:16.049+00:002014-12-01T23:12:16.049+00:00In most cases, whats the point? Any Object method ...In most cases, whats the point? Any Object method argument can accept a null anyway, so why not use that ability and call Optional.ofNullable(). Forcing API users to wrap their input in an Optional just to call your method is being mean to your users.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-18285444957639504842014-12-01T22:43:27.348+00:002014-12-01T22:43:27.348+00:00Optional as return type OK, as Bean property field...Optional as return type OK, as Bean property field NOK - how about Optional method arg - yay or nay?Michael Vorburger.chhttps://www.blogger.com/profile/11228070120924430806noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79392388212653696462014-11-09T18:02:45.163+00:002014-11-09T18:02:45.163+00:00@Nicolai: Yes on thoughtless try-catch-ignore. And...@Nicolai: Yes on thoughtless try-catch-ignore. And yes checked exceptions are useful. My argument with Optional is that get() is too terse. You want the easiest thing to be the right thing, but with this API the easiest thing is the wrong thing.Lawrence Kesteloothttps://www.blogger.com/profile/08175600004629340681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-77729399815552336452014-11-09T12:19:21.951+00:002014-11-09T12:19:21.951+00:00@Lawrence:
This is not the best place for a length...<b>@Lawrence</b>:<br />This is not the best place for a lengthy discussion so I don't want to start one. But from my experience I'd say that (b) can be an issue (see <a href="http://blog.codefx.org/techniques/intention-revealing-code-java-8-optional/#Null" rel="nofollow">my blog post</a>).<br /><br />About the enterprise programmers exchanging "foo" with "foo.get()" just to be done with it. That's really sad! I'm fortunate not to have encountered many developers of which I think that they'd do something like that routinely. But couldn't the same argument be made about exceptions? Surely you've seen try-catch-ignore. That doesn't stop us from thinking that exceptions are a valid part of Java.<br /><br /><b>@Anonymous</b>:<br />Yes an API can return null instead of Optional. But that's just sick! ;)<br />Btw, <a href="http://sourceforge.net/p/findbugs/feature-requests/297/" rel="nofollow">FindBugs has a rule to prevent that</a>.Anonymoushttps://www.blogger.com/profile/10683069431949943898noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-55203838820665404402014-11-06T22:10:43.090+00:002014-11-06T22:10:43.090+00:00I agree that Optional should not be used as a bean...I agree that Optional should not be used as a bean property. Apart from the technical reasons you give (serializability, memory) it makes re-use harder: beans are often domain model classes, and what's optional in a domain (e. g. car insurance) can vary (e. g. from country to country).<br /><br />I also like the fact that Optional in SE 8 is monadic and the fluent style of programming that enables, as in<br /><br />Optional name = person<br /> .map((Person p) -> p.getCar())<br /> .map((Car c) -> c.getInsurance())<br /> .map((Insurance ins) -> ins.getName());<br /><br />That's a definite improvement over null-checking Java 7 code!Sebastian Millieshttps://www.blogger.com/profile/11109789625080423651noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-47033007319513442092014-11-06T11:14:42.150+00:002014-11-06T11:14:42.150+00:00If you know what your doing, get() might be legiti...If you know what your doing, get() might be legitimate.<br />If you don't, you'll use get() everywhere, and your code will have the same behavior as without the Optional class. NPE replaced by NSEE.<br />Then one day maybe, you'll discover orElse(), and your life will change.<br /><br />But I have another concern : my function returning en Optional can still return null. Right ?<br />So, I'll have one more case to test, for poorly written libraries :<br /><br />if (personResult==null || !personResult.isPresent()) return;<br /><br />Instead of <br /><br />if (personResult==null) return;<br /><br /><br />:-(Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-84704674846184204982014-11-06T05:16:23.695+00:002014-11-06T05:16:23.695+00:00I agree with your point (a). With point (b), it...I agree with your point (a). With point (b), it's not usually a problem to find fault.<br /><br />My basic point is that most enterprise programmers I know will simply create a mental rule: When you have a variable of type Optional, always use foo.get() to access it. It'll be a thoughtless substitution of "foo.get()" for "foo". That's it. (I'm exaggerating somewhat, but not a ton.) The type has too soft an API to be useful.Lawrence Kesteloothttps://www.blogger.com/profile/08175600004629340681noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-22011659107907382522014-11-06T00:18:06.890+00:002014-11-06T00:18:06.890+00:00This has come too late in the life of Java the lan...This has come too late in the life of Java the language to be of any practical use. It will most likely confuse developers and create differing code styles in the same code base. Scala had this from the get go, and all APIs relevant to this support it, idiomatically (monads, matchers, collections, etc). There is too much enterprise Java code around that holds the language back at this point... Anonymoushttps://www.blogger.com/profile/14641827837217338350noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-64415954943665348632014-11-05T23:26:13.944+00:002014-11-05T23:26:13.944+00:00But isn't the reason for the missing null chec...But isn't the reason for the missing null checks that there is no easy way to know when to do one? You can't do it everywhere... You could read every method documentation (hoping there is a detailed one) but who does that? (I know that both are lame reasons. But from my experience those are exactly the reasons why null becomes a problem - besides sloppy implementation of course.)<br /><br />So having the type hit you over the head with the fact that there might very well not be a value, should really help. Especially if you can be sure that in all other cases, there will be a value. Hence there can never be null.<br /><br />And don't forget failing fast and the blame game. Calling 'Optional.get' and getting an exception ...<br />(a) ... can very well happen much earlier than the NPE (who knows where that accidental null otherwise goes) -> Fail Fast<br />(b) ...makes it very clear who's at fault and what to do about it.Nicolai Parloghttp://blog.codefx.orgnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-86518141540698155542014-11-05T23:19:07.041+00:002014-11-05T23:19:07.041+00:00I don't agree to only use Optional as a method...I don't agree to only use Optional as a method's return type. I know it was the intended meaning[1] but this alone does not convince me.<br /><br />I recommend using it everywhere where null is a legal value[2]. If that happens to be in lots of places, something is wrong with the design. Using an explicit type at least makes that obvious. With good design it becomes rare and then I see no reason why not to use it in every situation.<br /><br />For example you might have a field which is null half of the time (and it has to be this way because otherwise we're not even having this conversation). What better way to express is partly absent nature than by making it optional?<br /><br />[1] http://blog.codefx.org/jdk/dev/design-optional/<br />[2] http://blog.codefx.org/techniques/intention-revealing-code-java-8-optional/<br /><br /><br />PS: I hope this only shows up once. I couldn't publish one way, so now I try another.Nicolai Parloghttp://blog.codefx.orgnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-55626916946540579232014-11-05T23:07:22.378+00:002014-11-05T23:07:22.378+00:00I do many code reviews for enterprise Java program...I do many code reviews for enterprise Java programmers. I don't think this will be much safer than null. Anyone who currently just dereferences a pointer without checking null will, instead, just call get(). NoSuchElementException is unchecked, so they won't even know about the exception. The API should either have thrown a checked exception or should have had a long and unpleasant name, as Brian suggests. (Or left out altogether, which is the only compile-time safe thing to do.)Lawrence Kesteloothttps://www.blogger.com/profile/08175600004629340681noreply@blogger.com