Java is getting true pattern matching in version 15, what a time to be alive!
New Features in Java 14
11–20 of 188 posts
Re: New Features in Java 14
#12Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile.
Re: New Features in Java 14
#13"Helpful NullPointerExceptions": One of the biggest pain points of Java, probably the biggest. Good that it's being finally solved;
It's just better error messages (where within expression, not just which line).
Re: New Features in Java 14
#14Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
The difference is that the choice of Optional is deliberate in the parts of code where None is a valid value. In java you have no first class way to indicate that null isn't an expected value for some variable and so type checker can't block it. In rust type checker wont let None slip in accidentally if you don't use Optional.
Re: New Features in Java 14
#15Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
In Java you're passed a reference to an object. Might it be null? Can it be null? Who knows! Mostly you're just going to ignore the possibility and hope for the best.
In Rust you're passed a reference to an object. Can it be null? No, it simply can't! There does not exist a magic "null" value for references. To represent the possible absence of a value, you explicitly encode it into the type system by using `Option`.
Re: New Features in Java 14
#16Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
I can't speak for Rust, but in Go accessing properties of nil objects and dealing with 0-values for non-pointer values can cause bugs in certain contexts where you "let your guard down".
func getFoo() (*Foo, error)
func main(){
foo, err := getFoo()
if err != nil {
// be an adult and handle your error
}
foo.Work()
// panic because whoever implemented getFoo returned a nil object
}
Re: New Features in Java 14
#17Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
And you can write sth.unwrap() in Rust, and then it panics when it is null.
Kotlin solves it much better. sth?.do_something() ?: nothing_to_do
Re: New Features in Java 14
#18"switch expressions", "text blocks". I haven't used Java for 15 years but it's one of the most mature languages out there. I'm surprised it's only just getting these pretty standard features now.
Re: New Features in Java 14
#19Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
Using the `match` method, you can guarantee that in the `some()` branch, v is not null, and will never be null.
In the `if == null` method, the `something` reference is null, but if you have functions that also reference `something` down the line, you're going to have to check it again for null-ness.
Re: New Features in Java 14
#20Earlier quoted context omitted.
Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a d…
This specific pattern can be re-written as
sth.map(|v| do_something);