tag:blogger.com,1999:blog-741750605858169835.post328349887107009924..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Java 7 - Null-default and Null-safe operatorsStephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-741750605858169835.post-39692986314164782392009-01-20T11:00:13.000+00:002009-01-20T11:00:13.000+00:00Stephen, in the case of a null-default operator th...Stephen, in the case of a null-default operator that contains a throws, it could be rewritten in existing java keeping definite assignment intact.<br /><br />In my example, the code<br /><br />return map.get(key) ?: throw new IllegalArgumentException("Cannot find " + key); <br /><br />could be rewritten as<br /><br />final Object result;<br />Object temp = map.get(key);<br />if (temp != null) {<br /> result = temp;<br />}<br />else {<br /> throw new IllegalArgumentException("Cannot find " + key);<br />} <br />return result;<br /><br />As I see it, at the return statement, the compiler has made sure that every code path either assigned the variable result exactly once or thrown an exception.<br /><br />On the other hand, I agree it would complicate the spec. I think however it would be a good idea to at least see if we could keep this option open for a next java release.Roel Spilkerhttp://spi.googlecode.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-66191077636318711182009-01-16T00:41:31.000+00:002009-01-16T00:41:31.000+00:00Kieron: Yes, I think your situation is unusual. Lo...Kieron: Yes, I think your situation is unusual. Lots of code is written to handle nulls all the time (and using null in an API can be a valid choice if used carefully).<br /><br />Lasu: I hadn't considered array access, but there may be a case to support it.<br /><br />Tim: I'd argue its pretty common when dealing with deeply nested bean/POJO structures to have to handle any of the layers potentially being null, and you not actually caring.<br /><br />Roel: I believe that converting throw to an expression would cause a non-trivial piece of work in the spec wrt definite assignment and the like. As such, I don't see that happening in Java 7.<br /><br />Vineet: Yes, ?: is the C# ?? operator IIUC.Stephen Colebournehttp://jroller.com/scolebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-11177130161640428082009-01-15T17:26:47.000+00:002009-01-15T17:26:47.000+00:00Is "?:" (null-safe operator) similar to ...Is "?:" (null-safe operator) similar to C# "??" (null coalescing operator)?Vineet Bhatiahttp://web.me.com/vineetbnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79338141468381654992009-01-13T11:57:48.000+00:002009-01-13T11:57:48.000+00:00Is there some way to use the null-default to also ...Is there some way to use the null-default to also throw exceptions? For instance<br /><br />return map.get(key) ?: throw new IllegalArgumentException("Cannot find " + key);<br /><br />Currently, since throw is not an expression, you can't use <br /><br />Object result = map.get(key);<br />return result != null ? result : throw new IllegalArgumentException("Cannot find " + key);<br /><br />But since we are adding sugar, we could have the compiler generate the necessary bytecode if it finds a throw keyword.Roel Spilkerhttp://spi.googlecode.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-45558983860301093632009-01-09T20:42:44.000+00:002009-01-09T20:42:44.000+00:00I agree with many commenters that null should be a...I agree with many commenters that null should be avoided in APIs.<br /><br />I like "?:" because it helps handle calls to APIs that return null inappropriately. In this example, getHistory() should return a null object but returns null instead. The "?:" operator makes it easy to fix that at the call site if you can't change the API:<br /><br /> History history = user.getHistory() ?: NULL_HISTORY;<br /> List dates = history.getDates(); // NULL_HISTORY returns an empty list<br /><br />I'm leery of "?." because it implies that the correct null object for a type is one that returns null for every method, so it propagates nulls instead of eliminating them. The above example would become:<br /><br /> List dates = user.getHistory()?.getDates();<br /><br />and you still have to deal with dates == null.<br /><br />There are times when returning null is reasonable, e.g. when searching for something. It implies the need for special processing. For example, you may design your API so that findUser can return null but the other methods can't:<br /><br /> User user = userManager.findUser(userName);<br /> if (user == null) {<br /> // special handling because user can't be found<br /> } else {<br /> List dates = user.getHistory().getDates();<br /> // dates cannot be null<br /> }<br /><br />This would be the wrong way to do it (in my opinion):<br /><br /> List dates = userManager.getUser(userName)?.getHistory().?getDates();<br /> if (dates == null) {<br /> // why are we here?<br /> // user wasn't found or user doesn't have history or history doesn't have any dates<br /> }Tim Keithnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-4266915442542615792009-01-08T19:37:04.000+00:002009-01-08T19:37:04.000+00:00Hi!
I forget to mention it again but it would be r...Hi!<br />I forget to mention it again but it would be really bad if some thing like:<br />array.?.[index]<br />would be not possible.<br />^__^<br /><br />I have some work now, but after it's done I'll prepare construction for methods that are able to return more than one value.Lasu aka Marek Kozielhttp://lasu2string.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-76440409499750647452009-01-07T12:56:40.000+00:002009-01-07T12:56:40.000+00:00Perhaps my use of Java is unusual, but I really do...Perhaps my use of Java is unusual, but I really don't see a big need for this sort of null handling.<br /><br />The only support for null I would like (actually, love) in Java is being able to say that something should or not should not be null, and let the compiler complain against possible breaches.<br /><br />Virtually all of our software does not use nulls, and so they have ceased to be a problem for a long time now.<br /><br />Apart from using 3rd party libraries (fairly rare here), the only need I see with this is for legacy code? After all, who uses null in an API these days? Is that is generally the case, should we add something that only satisfies a legacy use?Kieron Wilkinsonnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-7575266945467484542009-01-07T08:02:12.000+00:002009-01-07T08:02:12.000+00:00Collin: In v0.1 of the proposal I outlined a possi...Collin: In v0.1 of the proposal I outlined a possible null object design. However, I removed this as it makes the overall solution much more complex.<br /><br />Collin: "Assuming you don't care and want to keep on processing ... there is nothing to insulate the code that comes after from the null.<br /><br />Most of the time I would expect to write something like:<br /><br />if (a.?b?.c != null) {<br />// process c<br />}<br /><br />Mikko: I have nothing against nullity in types. In fact I prefer it. But it is a complex change for Java (easy for new languages like Fan). And as Fan shows, you still need these two operators even when you have nullity in types.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42838811826486109562009-01-07T01:43:50.000+00:002009-01-07T01:43:50.000+00:00+1 for this and
+1 for fcm+1 for this and<br />+1 for fcmsergenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-68023050018891122702009-01-06T22:44:54.000+00:002009-01-06T22:44:54.000+00:00My money is on non-null types (e.g., String!).
If...My money is on non-null types (e.g., String!). <br />If redundant null-checking is the problem, then removing the nullability is the most effective "roots" solution, not ill-specified syntactic sugar.<br /><br />Let's demonstrate the importance of non-null types via an analogy. You write this every day:<br /><br />if(arg == null) {<br /> throw new IllegalArgumentException("arg == null");<br />} else {<br /> return arg.substring(4); // or omsething<br />}<br /><br />But this is conceptually similar to:<br /><br />if(!(arg instanceof String)) {<br /> throw new IllegalArgumentException("!(arg instanceof String)");<br />} else {<br /> return ((String)arg).substring(4);<br />}<br /><br />You would never write the latter kind of snippet; why do you keep up with writing the former?Mikko Kauppilanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-25057402083604083122009-01-06T19:28:09.000+00:002009-01-06T19:28:09.000+00:00I really like the null-default operator. My only q...I really like the null-default operator. My only question is what do you do after a line like this?<br /><br />String result = getFooMayBeNull()?.getBarMayBeNull()?.getResult();<br /><br />If result is null what operation failed?<br /><br />Assuming you don't care and want to keep on processing. Either I need to assign a default value or every time I use result I must use '?.' operator. <br />There is nothing to insulate the code that comes after from the null. <br />The null handling just gets passed on further and further down the chain until someone decides to assign a value, or you get an NPE. <br />I think it would be helpful if a class could implement an interface that provided a nullObject() method. <br />This value would get returned by default by the '?.' operator. <br />So for a List the implementation of nullObject() would return Collections.emptyList().<br /><br />Making code like this work.<br /><br />foreach(Person p : group.?getPeople()){<br />//.. code<br />}<br /><br />Also String might return "" for .? making this safe.<br /><br />String result = getFooMayBeNull()?.getBarMayBeNull()?.getResult();<br />if(result.equals("something"){<br />... logic<br />}<br /><br />The only problem is if you actually want a null. But do you ever want a null if you are using '.?' ?<br /><br />The only other issue is that the nullObject() method would have to come from a static interface method or be added to object.Collinhttp://aberrantcode.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-49739932759052884572009-01-06T18:01:43.000+00:002009-01-06T18:01:43.000+00:00Hamlet: Using annotations for nullity is a hack IM...Hamlet: Using annotations for nullity is a hack IMHO. A proper language level integration provides much more power and control (and interaction with other features). The typical syntax (backwards compatible) for Java would be:<br /><br />String str = ... // string that can hold null<br />String! str = ... // string that cannot hold nullStephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-79248288514705686322009-01-06T16:41:11.000+00:002009-01-06T16:41:11.000+00:001.
Nullity is wrong path.
We can use if, or add va...1.<br />Nullity is wrong path.<br />We can use if, or add validators to ArrayList.<br /><br /><br />2.<br />null-default operator in current look is bad idea.<br />func(a,b,c,d){<br />return ((a?.b?:b)?.c:?c):?d;<br />}<br />realy bad to read in some cases.<br /><br /><br />3. <br />The rule:<br />The RHS expression is only executed if the LHS expression yields null<br />Need to be considered, cos it will give a little speed but it will kill language evolution.<br />U see that?<br /><br />This is a personal weblog, I do not speak for my employer.Lasu aka Marek Kozielhttp://lasu2string.blogspot.com/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75497229311601516302009-01-06T14:53:52.000+00:002009-01-06T14:53:52.000+00:00@Daniel /me vomits a little in his mouth
Every ti...@Daniel /me vomits a little in his mouth<br /><br />Every time someone posts that class as a solution I go cross-eyed.<br /><br />To abuse a JWZ quote:<br /><br />'Some people, when confronted with a problem, think "I know, I'll use Option from functionaljava!" Now they have two problems.'Justin Leehttp://antwerkz.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10511769807307740432009-01-06T14:41:56.000+00:002009-01-06T14:41:56.000+00:00I think JSR 308 _is_ about adding Nullity to the t...I think JSR 308 _is_ about adding Nullity to the type system... with the @Nullable and @NonNull annotations. You can set a default nullity for your source and then effective have all fields and variables marked @NonNull unless you specifically override. <br />I realize you're asking for something slightly different than this... but I spend a few hours looking at the JSR 308 spec and FAQ and came away impressed with it.Hamlet D'Arcyhttp://hamletdarcy.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-89833553061941793792009-01-06T12:57:01.000+00:002009-01-06T12:57:01.000+00:00Daniel: One look at that javadoc URL would scare a...Daniel: One look at that javadoc URL would scare away 99% of developers IMHO. Functional programming is far from the norm today, and far from what Java is intended to be (ie. forcing functional paradigms into Java doesnn't make sense).<br /><br />Reinier: I discuss nullity in types in the proposal. I believe that this are a good idea, however it is specifically not possible for Java 7 (type changes are not permitted as they are not 'small'). Further, the Fan language demonstrates that the proposed null-safe and null-default features are still needed even when you have nullity in types. I also think that your proposal of 'don't care' adds additional complexity and is probably not needed.Stephen Colebournenoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-59093155726294623922009-01-06T11:45:24.000+00:002009-01-06T11:45:24.000+00:00+1 for enhanced null handling
-1 for "move nu...+1 for enhanced null handling<br />-1 for "move nullity into the type system"Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-75783993975578158302009-01-06T09:30:12.000+00:002009-01-06T09:30:12.000+00:00I say we go whole hog and nail this problem once a...I say we go whole hog and nail this problem once and for all: Move nullity into the type system. This is more complex than simply having 'allows null' and 'does not allow null' in the syntax, just like generics has wildcars, you also need 'I don't care if null is allowed or not', which is different from 'allows null'.<br /><br />But, the good news is, the strangeness is no different from what we're already used to with generics, so in the end its not hard to grok, and it definitely solves the problem. Full proposal writeup here: http://www.zwitserloot.com/2008/10/23/non-null-in-static-languages/Reinier Zwitserloothttp://www.zwitserloot.com/2008/10/23/non-null-in-static-languages/noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-83287577854167098862009-01-06T05:38:29.000+00:002009-01-06T05:38:29.000+00:00It really should cut down on the boiler code that ...It really should cut down on the boiler code that is induced for NULL checks over.<br /><br />Using functionaljava's Option is a only a solution when you are dealing with your own code, but development spanning multiple third-party libraries, it probably won't be an always an option. Second, as shown in the above example primitive wrappers and (un)boxing is taken care of, but with Option it won't be possible.Sandeep Guptanoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-10482785852563586662009-01-06T02:00:13.000+00:002009-01-06T02:00:13.000+00:00I question that this "tackles the heart of th...I question that this "tackles the heart of the null issue".<br /><br />It's just a bit of extra syntactic sugar... I would suggest that perhaps something like functionaljava.org 's Option is a better solution: <br /><br />http://functionaljava.googlecode.com/svn/artifacts/2.17/javadoc/fj/data/Option.htmlDaniel Alexiuchttp://justsomejavaguy.blogspot.comnoreply@blogger.com