Just use C#. :P
Not always an option, and even if that is possible, plenty of existing code doesn't work with non nullable references.
Retrofitting null-safety onto Java at Meta
131–140 of 230 posts
Re: Retrofitting null-safety onto Java at Meta
#132Earlier quoted context omitted.
Yes, it's always been possible to check for nulls at runtime. Personally I use notNull(..) over @NonNull since it actually fires when you expect it to (as opposed to whether your framework dispatcher interceptor trigger decided to invoke it)
isn't @NonNull just a syntactic sugar for adding checkNonNull() call as first statement to the function declaration in compile time, or am I mistaken? Just like lombok, it is supposed to generate code that checks null arguments, from what I know.
I tried:
@Test
public void foo() {
bar(null);
}
void bar(@NonNull String param) {
System.out.println(param);
}
import lombok.NonNull;
import javax.validation.constraints.NotNull;
import io.micronaut.core.annotation.NonNull;
import org.springframework.lang.NonNull;
import reactor.util.annotation.NonNull;Re: Retrofitting null-safety onto Java at Meta
#133This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"
> getAccount().getContact().getPhoneNumber() Every time I see people "deal" with this problem, it looks like this: if (getAccount() != null && getAccount().getContact() != null && getAccount().getContact.getPhoneNumber() != null) { // do something } // don't put an else condition in, just keep going and let the program // produce the wrong result in a confusing way when it happens in production I actually blame rampa…
[deleted]
Re: Retrofitting null-safety onto Java at Meta
#134This is just covering up design problems. NPEs show you were you have design deficiencies. If you have getAccount().getContact().getPhoneNumber() and contact is null, you'll get an NPE. The question shouldn't be: "How do I shove the NPE under the rug for the next 1337 coder to deal with?", the question should be: "How did I initialize an Account without a Contact?"
> getAccount().getContact().getPhoneNumber() Every time I see people "deal" with this problem, it looks like this: if (getAccount() != null && getAccount().getContact() != null && getAccount().getContact.getPhoneNumber() != null) { // do something } // don't put an else condition in, just keep going and let the program // produce the wrong result in a confusing way when it happens in production I actually blame rampa…
That sort of design easily leads to a god object.
Class based OOD is way harder than that. There's a reason codebases are full of these train wrecks (the unofficial official name of the pattern). And it's not because of auto generation and/or laziness. It's because, despite what's on the tin, passable - nevermind good - OOD doesn't look anything like how we actually think of objects as humans.
Re: Retrofitting null-safety onto Java at Meta
#135Earlier quoted context omitted.
Other jvm languages compile to the byte code and fix this by inlining the optional transparently. What you mean by “at a language level” would break the byte code for jars compiled with older jdks.
Breaking backward compatibility is not the end of the world.
Thank god the Java language designers don’t share your point of view.
Re: Retrofitting null-safety onto Java at Meta
#136Earlier quoted context omitted.
Kotlin interops nicely with Java but it's not null-safe (all references from Java are assumed non-null).
That is wrong all, non annotated Java code gets a special type denoted with a ! . You can use ?. or assign it to a new val with ?: return. Or you throw all the null safety away and write unsafe java code but in Kotlin the same as the Java code you're working with.
You can use ?. or assign to a nullable type. Or you can get a NPE at runtime. Which is to say, it's not null-safe.
Re: Retrofitting null-safety onto Java at Meta
#137Earlier quoted context omitted.
I'd rather have the decade of increased productivity.
Increased productivity comes in various ways. A more popular language often has a better ecosystem that helps productivity, and adding lots of language features quickly is a hindrance to huge popularity. This might not be the case for many here, but most programmers prefer fewer features than more, and the most popular languages are also often those that can be taught as a first language, which also requires restrain…
I know vastly more programmers that have abandoned Java than swapped to it.
That’s not to say it failed. Java is one of the most popular languages, but it does suggest real issues with the current approach.
Re: Retrofitting null-safety onto Java at Meta
#138Earlier quoted context omitted.
It is the same old story, later repeated with agile manifesto, REST, and so on. They became misunderstood and abused by enough people that the terms stopped meaning anything useful in public space. When I hear a company say "we're Agile, we are doing REST" etc. I just roll my eyes and think to myself: unlikely. Over the years I figured out the right way to use all of these things: as resources with solutions to frequ…
One interesting point is how many think there is Java code on GoF.
Wow, just came up with fantastic interview question (just kidding).
But, yeah, this is a good point. I interview senior engineers (mostly Java) a lot and I work with a lot of people like managers, tech leads, architects and senior engineers and I have the feeling that almost nobody has ever actually read any of the things that they are talking about.
Re: Retrofitting null-safety onto Java at Meta
#139Earlier quoted context omitted.
That is wrong all, non annotated Java code gets a special type denoted with a ! . You can use ?. or assign it to a new val with ?: return. Or you throw all the null safety away and write unsafe java code but in Kotlin the same as the Java code you're working with.
You can use ?. or assign to a nullable type. Or you can get a NPE at runtime. Which is to say, it's not null-safe.
So you're in the exact same case as you were in Java, which was my third point. But the type is a special type to let you know what you're doing is unsafe.
Re: Retrofitting null-safety onto Java at Meta
#140So after working at Google for 6 years (and doing Java and other things prior) I went to Facebook and programmed in Hack for 4 years. Hack is actually a really interesting and convenient language in many ways. One way I really appreciated is how nullability is built into the type system. Having to deal with nullability in Java is actually way more of a chore than any of the verbosity that people normally complain about (eg boilerplate around anonymous classes).
The story I like to tell about how people abuse Java is this:
@nullable Optional
The way I like to describe this is "for when 3 values for your boolean just aren't enough" (since you obviously now have 4 states: 1) null 2) Not set 3) Set, true 4) Set, false).
I have a few rules that have held up v ery well over the years including:
1. If you don't do arithmetic on it and it's not an ID of some kind, it's almost certainly not a number (eg people who store SSNs as INT fields); and
2. It's almost never a boolean. You're almost always better off replacing any boolean with an enum. Not only is this typesafe but if done right adding an enum value will cause compiler errors because you've been exhausitve with switches without a default case.