Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Features in Java 14

blogs.oracle.com

Post reply on HN
Print view View original

41–50 of 188 posts

Re: New Features in Java 14

#41

Post by reificator »

fidelramos wrote: post #12
rakoo wrote: post #9

Earlier quoted context omitted.

> 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.

No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages.

The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don't have a secret (not)T that invisibly breaks everything.

Re: New Features in Java 14

#42

Post by skissane »

tadfisher wrote: post #39
mateuszf wrote: post #38

I wonder about records - they would be great for simplified implementation of immutability, but they seem to not provide a way to copy with a subset of modified fields - like in Scala: case class Person ( firstName: String, lastName: String, age: Int ) you could create an instance like this: val emily1 = Person("Emily", "Maness", 25) and then create a new instance by updating several parameters at once, like this: //…

Java lacks default arguments for functions, which makes that particular API infeasible without adding support for such. They could generate "withFoo" methods or even builder types, but that would butt up against developer preference, so it's probably best to leave it up to developers or a third-party library. Kotlin has a very similar feature in its data classes, FWIW.

> Java lacks default arguments for functions, which makes that particular API infeasible without adding support for such

I really wish Java would add both default arguments for functions, and also support for passing function arguments by name.

One of these days...

Re: New Features in Java 14

#43

Post by sigzero »

dionian wrote: post #23
redact207 wrote: post #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.

it's always moved slow on purpose... one of the language's greatest features is backwards compatibility and stability it's purposefully dead simple. this is why many of us switched to alternative JVM langs ... Java can't keep up with the innovation other Langs have without breaking its philosophy of slowmoving/backwards compat

That was before and this is now. Java is adding things quite frequently now.

Re: New Features in Java 14

#44

Post by crooked-v »

reificator wrote: post #41
fidelramos wrote: post #12

Earlier quoted context omitted.

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.

No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don…

Typescript is another one where null and undefined are unique singleton types, which are encompassed under the catch-all `any` type but, if strictness is turned on, are rejected by any other type matching.

    doThingA(param: any) // you can pass anything including null and undefined
    doThingB(param: object | number | string | boolean | bigint | symbol) // you can pass anything except null and undefined

Re: New Features in Java 14

#45

Post by sk5t »

justinhj wrote: post #7
cryptos wrote: post #5

Earlier 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.

Scala does a pretty good job too, with the help of build plugins you can avoid null polution (which normally comes from Java libraries) pretty well.

Build plugins - do you mean wartremover or something else?

Re: New Features in Java 14

#46

Post by imtringued »

rakoo wrote: post #9
cryptos wrote: post #5

Earlier 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…

>It might look more pleasant, but it doesn't "solve" anything, only shifts it in a different place.

It shifts it right into your face. You're forced to do something instead of pretending that everything could be potentially null. Since the only places where you can actually encounter "null" are documented you are no longer wasting your brain cells on the happy path where you are guaranteed to never see a null value when you don't expect it. Instead you can free up all that cognitive capacity to actually write correct code that handles null values.

Re: New Features in Java 14

#47

Post by imtringued »

reificator wrote: post #41
fidelramos wrote: post #12

Earlier quoted context omitted.

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.

No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don…

> No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages.

Are you sure? Each line of Java or Javascript can be equivalent to multiple `unwrap()` calls. You can't see them because the compiler is generating ([0]) them but they are there and there are many hundreds of thousands (or maybe even millions including dependencies) of them in most Java projects.

Here is an example: company.board.members.size() is equivalent to company.unwrap("NPE).board.unwrap("NPE).members.unwrap("NPE).size() and every single line in Java is like that. You can't opt out. You can't tell your coworkers to stop using "unwrap" during code reviews. The entire language forces you to do this in every single line that involves a reference.

[0] Well, it's actually just trapping the 0 address but it's equivalent.

Re: New Features in Java 14

#49

Post by riyadparvez »

dionian wrote: post #23
redact207 wrote: post #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.

it's always moved slow on purpose... one of the language's greatest features is backwards compatibility and stability it's purposefully dead simple. this is why many of us switched to alternative JVM langs ... Java can't keep up with the innovation other Langs have without breaking its philosophy of slowmoving/backwards compat

Not all features have to do anything with backward compatibilities. I agree with the fact that features should be added with caution cause new features can interact with existing features in a non-trivial way that will introduce lot of edge cases. But it's hard to see why a feature like text block would introduce more complexities.
Post reply on HN