tag:blogger.com,1999:blog-741750605858169835.post5189584762986607828..comments2024-01-24T14:53:02.919+00:00Comments on Stephen Colebourne's blog: Better nulls in Java 10?Stephen Colebournehttp://www.blogger.com/profile/01454237967846880639noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-741750605858169835.post-61143014948084733162015-11-22T19:21:40.537+00:002015-11-22T19:21:40.537+00:00So if it's only for notnull classes, it become...So if it's only for notnull classes, it becomes the same as the c# implementation, which in my opinion works.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-44283219919079263282015-04-23T23:59:24.770+01:002015-04-23T23:59:24.770+01:00Having used Java for many years, and Scala for the...Having used Java for many years, and Scala for the last few years, I'd say that Scala's Option has been a huge win in preventing NPE's. With Scala, I've come close to eliminating NPE's entirely, whereas with Java I expect NPE's routinely. So my answers to your questions are:<br /><br />Was null a billion dollar mistake? Yes.<br /><br />Does Optional everywhere lead to bad performance? Actually, you don't really use "Option everywhere". As it turns out, most stuff isn't optional. So the boxing overhead isn't an issue most of the time. If it becomes a performance problem, then avoiding Option is always, well, an option.<br /><br />The syntactic overhead is slightly annoying but (1) one gets used to it pretty quickly, (2) there are nice ways of making it more terse (e.g. applicative style), and (3) there are benefits to the syntactic overhead such as consistency with how other container types are treated (Lists, etc.) For example, Options have the same collections methods as everything else: map, flatMap, foreach, etc.diymoneyhttps://www.blogger.com/profile/08430796160553595191noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-23686577991609329162015-04-07T02:37:32.741+01:002015-04-07T02:37:32.741+01:00Nice post. Null is tricky, invaluable, and a nece...Nice post. Null is tricky, invaluable, and a necessary evil all at once.<br /><br />I kind of agree with Cedric re nonnull. Although an IDE can be made to highlight a nullable declaration differently than a nonnullable one, in general it would be confusing to deal with a nonnull class modifier for the reasons he points out. That said, I agree with your more general point that nonnull should be the default. But assuming that ship has sailed, the nonnull type indicator (!) tossed around in other discussions, both Java and C#, seems like the pragmatic choice.<br /><br />Personally, I'm not convinced nullable state is as big a problem as many claim. I despise null checks as much as the next guy, but a lot of state out there is mutable and a lot of that mutable state is at one point in its life-cycle nullable. Just sayin'. I'll exercise restraint and not rant about this.<br /><br />Another part of me simply wants Oracle to break free of the innovator's dilemma they seem to be in and finally create a Java 2.0, shed all the baggage, and join the 21st century. Java 1.x is a good thing, but it's necessarily stuck in the past and will remain there forever as long as there is an industry depending on it. But there's a growing population of new programmers building new software not in Java at least partly because Java suc... er... hasn't kept pace. If Oracle wants to recapture or at least tap into this market segment and continue to innovate, they need to consider forking Java 2.0.<br /><br />The Java 2.0 language needs to remain Java, not Groovy, not Scala, not Closure, or any of the others. But it also needs to fix things, the big ones, that keep it firmly planted in 1999. The Java 2.0 VM needs to be redesigned from the ground up with polyglot in mind as well as many other concerns (hint: rape and pillage the CLR). And for f**k sake don't provide method overloading!<br /><br />Anyway, great post as usual.Scotthttps://www.blogger.com/profile/06344063507016315474noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-73507902824354828322014-12-03T22:58:17.022+00:002014-12-03T22:58:17.022+00:00> I used the word "slight" because I ...> I used the word "slight" because I see it more like a really useful shortcut than a new feature.<br /><br />Not exactly a shortcut. The important part (for me) is the differentiating between nullable and non-nullable references. With a nullable reference, you can't use plain `.`, so `?.` and `!.` are the only choices (unless you make the compiler recognize `a!=null ? a.b : whatever` like Kotlin does).<br /><br />> IMHO the NPEs that this article will fix are the most obvious ones<br /><br />Agreed, but the obvious ones are more abundant and can get costly too if they slip through CR and tests.<br /><br />> Therefor, does it warrant changing the default for null management in the whole language?<br /><br />IMHO yes, as the change is backward compatible (old sources get recognized as old and can be compiled) and it's a change in the right direction. Moreover, it's small change and it makes all the @Nullable, @Nonnull, and @NotNull crutches obsolete.<br /><br />> if the problem lies between the chair and the keyboard, are you sure you want to heavily patch the language?<br /><br />The problem sort of always lies there and the change seems to me pretty trivial when compared to lambdas.<br /><br />My experience tells me that it's always good to be explicit and this feature allows to be explicit about nullness with a very terse and clean syntax. Alone the fact that it documents what may be null is IMHO worth it.maaartinushttps://www.blogger.com/profile/00411808646708588421noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-36133001838440912992014-12-03T14:50:03.401+00:002014-12-03T14:50:03.401+00:00> The big improvement is making you aware of th...> The big improvement is making you aware of the possibility of `person` and `address` being null and forcing you to decide between the null-safe and throwing syntaxes.<br /><br />I used the word "slight" because I see it more like a really useful shortcut than a new feature.<br />Don't get me wrong I'm not shooting down the importance of dereferencing, I'm doubting of the cause here.<br />The really tricky NPEs I've seen so far came from bad design and/or poor management of external factors : bad use/understanding of frameworks, external configuration, lazy loading, bad input validation (file, user input..).<br />These get mostly fixed by fundamentals, documentation and testing... not at compile time.<br /><br />IMHO the NPEs that this article will fix are the most obvious ones, not the ones that cost hours (and money) to debug. Therefor, does it warrant changing the default for null management in the whole language?<br />What I mean is : if the problem lies between the chair and the keyboard, are you sure you want to heavily patch the language?<br />Or maybe my reasoning is flawed somewhere ?<br />Or maybe I'm just used to limping around a clunky language feature so much, that I don't see the point of fixing it?Anonymoushttps://www.blogger.com/profile/11029412475864198710noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-85531437646313590722014-12-03T12:59:55.998+00:002014-12-03T12:59:55.998+00:00> I agree with Salam Kaser, you can't "...> I agree with Salam Kaser, you can't "fix" poor understanding of fundamentals.<br /><br />Right, but this is not what this post is about. Whenever you need to access a member of `a` which is not proven to be non-null, you're making a decision what should happen for null. The problem is that you're not always aware of this decision and/or the nullability of `a`.<br /><br />Not allowing `a.` for nullable `a` makes this decision explicit. The compiler forces you to use either `.?` to handle null safely or `!.` (Kotlin syntax) to throw.<br /><br />> NPEs are the "division by zero" of object instanciation in my opinion.<br /><br />Right, but division by zero is so rare that nobody cares. There are quite a few big programs using no division at all (or a division by a constant only), but there is none doing no dereferencing.<br /><br />> We already have plenty of tools to prevent / account for it properly (compiler warnings, IDEs, Optional, Validators, utilities).<br /><br />We don't have anything good. `Optional` costs performance, by design should not be used for fields, leads to forking between Optional-using and null-using libraries, and can't be used in thousands of existing libraries. All the others need some annotations, which are nothing but a too verbose and weak alternatives to this proposal.<br /><br />> The only slight improvement I like is the syntactic sugar you proposed with null safe invocation : person#getAddress#getZipCode.<br /><br />The big improvement is making you aware of the possibility of `person` and `address` being null and forcing you to decide between the null-safe and throwing syntaxes.<br /><br />> In the wrong hands, it may very well lead to pushing programming errors further in a program.<br /><br />And in the good hands, it can lower the probability of NPE bugs by a huge factor.maaartinushttps://www.blogger.com/profile/00411808646708588421noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-74804559215308202162014-12-03T11:38:14.970+00:002014-12-03T11:38:14.970+00:00I agree with Salam Kaser, you can't "fix&...I agree with Salam Kaser, you can't "fix" poor understanding of fundamentals.<br />It would not come to your mind to try to provide "better division by zero in java 10" because you expect people to know a minimum about math. IDEs don't even warn you if you type : "float x = 10 / 0;".<br /><br />NPEs are the "division by zero" of object instanciation in my opinion.<br />We already have plenty of tools to prevent / account for it properly (compiler warnings, IDEs, Optional, Validators, utilities).<br />The only slight improvement I like is the syntactic sugar you proposed with null safe invocation : person#getAddress#getZipCode.<br />In the wrong hands, it may very well lead to pushing programming errors further in a program.<br /><br />Overly protective default behavior brings well documented troubles in JavaScript : it takes even more understanding of the language to figure out how it compensates for "mistakes".<br /><br /><br />Bottom line, you will never prevent poor understanding and bad design, and this is not limited to programming... heck, some people microwaved pets.Anonymoushttps://www.blogger.com/profile/11029412475864198710noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-38216411768411271902014-11-29T03:29:36.946+00:002014-11-29T03:29:36.946+00:00Really looking forward to better nulls and value t...Really looking forward to better nulls and value types, would have been better if they target this feature for Java 9 instead of 10, given how fed up Java community is from null checks and NPEs.Javinhttp://javarevisited.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-21842361653064105052014-11-17T11:03:39.820+00:002014-11-17T11:03:39.820+00:00As the java.util. value based class, wouldn't ...As the java.util. value based class, wouldn't JVMs have the option of storing these similar to a primitive - on the stack or inline if being member of a class, instead of adding another level of indirection via a reference, which would put additional pressure on the heaptalking about massive collections of Optionals, which frankly sounds like a misuse of the structure anyways.Java training Jaipurhttp://www.sagacademy.com/java-development-training-jaipurnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-3064949384921692582014-11-16T22:41:24.277+00:002014-11-16T22:41:24.277+00:00Is there any bytecode change needed? To me it look...Is there any bytecode change needed? To me it looks like adding a bunch of "checkNotNull" should do. All legacy code would be treated as allowing null everywhere, unless external annotations get added (the Kotlin way). The biggest problem with null is that it may come in unexpected, and the compiler forcing you to add "?" solves it nicely.maaartinushttps://www.blogger.com/profile/00411808646708588421noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31718283604552954992014-11-16T22:29:10.427+00:002014-11-16T22:29:10.427+00:00I fully agree with you, but I'd go further and...I fully agree with you, but I'd go further and get red of the nonnull keyword. Just mark the source (and I mean mark the source, not add a compiler switch) as Java 10 and everything will be non-null. This mark could be something as simple as writing "package 10 com.foo.bar;". You need no keyword and no source level compatibility (a Java 10 compiler must be able to process older sources, but once you add the mark, all the syntax garbage like "int a []" and can raw types can go).maaartinushttps://www.blogger.com/profile/00411808646708588421noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-13457108457553338332014-11-10T22:29:53.235+00:002014-11-10T22:29:53.235+00:00This blog asks readers to imagine a future world w...This blog asks readers to imagine a future world where the whole of the JDK has been changed to use "nonnull". In that world, what is abnormal today will seem normal. Just as generics and lambdas are now normal. In this case, there is plenty of academic evidence to suggest that non-null is what most developers want as the default, and in my recent coding on Java 8, I find that most uses of null can be avoided. A String! solution for non-null simply won't cut it IMO, nor will Optional. Its the default that we need to change.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-6353563100685124992014-11-09T12:42:34.985+00:002014-11-09T12:42:34.985+00:00I guess there are many ways to implement this and ...I guess there are many ways to implement this and the "!" vs "?" discussion shows that it is no easy decision what to pick. But in general I think that something like this is very necessary and those difficulties should not stop the introduction of such an important feature.Anonymoushttps://www.blogger.com/profile/10683069431949943898noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-8489049218846803752014-11-07T17:37:18.903+00:002014-11-07T17:37:18.903+00:00Lovro gets it right. The problem with switches tha...Lovro gets it right. The problem with switches that modify how the compiler parses your code (and the class level nonnull annotation is just that, a switch) is that now interpreting the code becomes context dependent. Java has always stayed away from such switches for good reason.<br /><br />With my suggestion, a statement "String a" will always mean what we expect it to mean: a is a nullable reference.<br />Cedrichttps://www.blogger.com/profile/13274064962794267826noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-31118820055828241822014-11-07T08:44:43.282+00:002014-11-07T08:44:43.282+00:00The code would then become less readable, because ...The code would then become less readable, because every time you see a type somewhere in code you also must look at the class declaration to understand what it really means.Anonymoushttps://www.blogger.com/profile/14694674934291627657noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-42986673647855672702014-11-07T08:09:04.709+00:002014-11-07T08:09:04.709+00:00I don't, because by adding the "nonnull&q...I don't, because by adding the "nonnull" keyword, I'm flipping the default within that class. How it interacts with code that doesn't use the new keyword is the more interesting question.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-52013607728326755382014-11-06T22:14:42.792+00:002014-11-06T22:14:42.792+00:00For backward compatibility, I think you'd need...For backward compatibility, I think you'd need to introduce a symbol for nonnull-ness (e.g. !) instead of one for nullness (?):<br /><br />String a; // nullable<br />String! a; // nonnull<br />Cedrichttps://www.blogger.com/profile/13274064962794267826noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-62187424493503324522014-11-06T16:08:01.854+00:002014-11-06T16:08:01.854+00:00Very aware of it, but very unconvinced. Null is a ...Very aware of it, but very unconvinced. Null is a language-level problem, and annotations and checker are a poor band-aid.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-56850851653841530232014-11-06T16:07:16.415+00:002014-11-06T16:07:16.415+00:00The proposal doesn't break existing code. Only...The proposal doesn't break existing code. Only if the class has "nonnull" in its definition can you use the String? syntax. The hand-wavy theory is that the JVM/language can be taught to allow older bytecode to interoperate successfully.Stephen Colebournehttps://www.blogger.com/profile/01454237967846880639noreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-30387747552991169852014-11-06T16:02:22.265+00:002014-11-06T16:02:22.265+00:00They only exist on value types in C#, not class ty...They only exist on value types in C#, not class types. <br />But yes, making such a big change that breaks existing code so heavily doesn't seem like a good option. Maybe make the syntax the other way around, so a String! is a non-nullable class.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-52890153984445786952014-11-06T14:35:16.301+00:002014-11-06T14:35:16.301+00:00Hi, you might already be aware of the checker fram...Hi, you might already be aware of the checker framework and its nullness checker, but if you aren't you might want to take a look at it:<br /><br />http://types.cs.washington.edu/checker-framework/current/checker-framework-manual.html#nullness-checker<br /><br />They provide annotated JDK 7 and 8 and it's possible to have compilation fail on violations.<br />They also provide their own javac if you are targeting JDK 7 and want to use annotations in places that are only allowed since Java 8.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-741750605858169835.post-33251638023596558302014-11-06T09:24:02.290+00:002014-11-06T09:24:02.290+00:00The ? concept you describe has been in C# for many...The ? concept you describe has been in C# for many years, but still has failed to prevent most NPEs. These core concepts cannot work as afterthoughts in my view...Anonymoushttps://www.blogger.com/profile/14641827837217338350noreply@blogger.com