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

31–40 of 188 posts

Re: New Features in Java 14

#31

Post by whateveracct »

whateveracct wrote: post #29

With switch, records, and (soon?) sealed interfaces, Java will be more pleasant than ever. Would I ever choose it if I were in charge of a project? Probably not. But it is nice that the language is incorporating these proven features that make a huge difference. It'll make working in Java when I'm not in charge much nicer.

One question about sealed:

Does anyone know how it will play with type parameters in the interface? I know in Scala, you can simulate GADTs with that.

    sealed interface Expr {}
    record IntExpr(Integer i) implements Expr { }
    record StringExpr(String i) implements Expr { }
Will that be legal? And will switch be able to do its magic and carry that type variable through?

Re: New Features in Java 14

#32

Post by stevetodd »

anonymousiam wrote: post #24

Who cares about the new features? The new license makes it almost impossible to use Java without some form of payment to Oracle.

Ugh, false. This document goes into quite some detail explaining the situation and all the many options you have to not paying Oracle: https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjp...

Re: New Features in Java 14

#33

Post by Yhippa »

I've been doing mostly Java work in my career and I'm using more JS these days on the side. I'm envious of the rest, spread, and deconstruction functionality in ES6. Really, really, envious.

Re: New Features in Java 14

#34

Post by erik_seaberg »

tmpz22 wrote: post #16
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…

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 } Also worth noting dealing with boolea…

Go also has https://golang.org/doc/faq#nil_error, so interface != nil doesn't ensure it's safe to call any of its methods.

Re: New Features in Java 14

#35

Post by aw1621107 »

benibela wrote: post #17
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…

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

Rust does in fact have a ? operator [0], but it works slightly differently than Kotlin's in that it returns early if a None/Result is encountered instead of just resolving to that None/Result. If that isn't what you want, then Option::map() is a fine substitute.

[0]: https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

Re: New Features in Java 14

#36

Post by aw1621107 »

Spinfusor wrote: post #28
aw1621107 wrote: post #25

Earlier quoted context omitted.

> The new license makes it almost impossible to use Java without some form of payment to Oracle. Do you have a source for this claim? It sounds a bit extreme, to say the least, and I had the impression OpenJDK was licensed using fairly standard terms.

It's mostly FUD: it's only relevant for the Oracle JDK; it doesn't apply to OpenJDK (or the other open distributions by other orgs).

Glad to hear that; I thought I remembered reading something like that back when the license change was first announced, but I wasn't sure if something else had changed in the meantime.

Re: New Features in Java 14

#37

Post by smt88 »

Yhippa wrote: post #33

I've been doing mostly Java work in my career and I'm using more JS these days on the side. I'm envious of the rest, spread, and deconstruction functionality in ES6. Really, really, envious.

What would stop you from switching to Kotlin, which has those features and many more?

Re: New Features in Java 14

#38

Post by mateuszf »

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:

  // emily is married, and a year older
  val emily2 = emily1.copy(lastName = "Wells", age = 26)

Re: New Features in Java 14

#39

Post by tadfisher »

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.

Re: New Features in Java 14

#40

Post by reificator »

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…

That's a huge improvement.

It means that you've told the type system what it needs to support you.

If your function tells the type system you need a reference to a type, you get a reference to that type. There's no hidden timebomb in there where you might get something that supposedly is that type but can't be treated as that type.

This lets you write your functions to accept nulls where appropriate, and require some form of unwrapping at the call site otherwise. It tells you when you've missed something and it lets you refactor without having to constantly repeat all of your checks, once you know something is valid the type system reflects that for you.

In short if you have a T in rust, you know that it's not secretly a (not)T that is implicitly allowed anywhere a T can be.

Post reply on HN