New Features in Java 14 • Hacker News Board

Re: New Features in Java 14

#71

Post by jeswin » Wed, Mar 04, 2020, 4:35 AM UTC

Benjammer wrote: post #53

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: //…

You'd probably have to manually write a Builder in the Person record class. Then the callsite might look something like this: val emily2 = emily1.newBuilder() .lastName("Wells") .age(26) .build() I think the inner Builder pattern is common enough in immutable java object implementations that they might want to include that fully in the Record class generation at some point. Most immutable object libraries that I've s…

Why not do what JS does?

  val emily2 = { ...emily1, age: 30 };

This has many advantages, one being that it provably and declaratively creates a copy, which is not the case with the builder. In fact the obsession with methods (and hence the implied state) is what makes Java a terrible misfit for functional paradigms such as immutability.

Re: New Features in Java 14

#72

Post by lmm » Wed, Mar 04, 2020, 4:42 AM UTC

nine_k wrote: post #57

lmm wrote: post #54

Earlier quoted context omitted.

You can use named parameters if you're worried: val emily1 = Person(firstName="Emily", lastName="Maness", age=25) Scala's approach to constructors is a good example of convention over configuration; in Java 99.9% of classes have a constructor like: this.firstName = firstName; this.lastName = lastName; this.age = age; which is just ceremonial boilerplate that obscures the actual logic of what the class is doing (an ID…

Lombok solves this for Java.

Using Lombok ends up being just as much effort as using a different JVM language, and the rewards are smaller.

Re: New Features in Java 14

#73

Post by lmm » Wed, Mar 04, 2020, 4:50 AM UTC

nitrogen wrote: post #62

lmm wrote: post #55

Earlier quoted context omitted.

Does Kotlin have anything to let you treat data classes in a generic way like you can do with Shapeless in Scala? That's where the real power comes IME - e.g. look at Circe where you can derive JSON encoders/decoders for arbitrarily nested case classes at compile time, so you have zero boilerplate but still get compile-time type safety that stops you from accidentally trying to serialise a file handle or semaphore.

There is the currently experimental kotlinx.serialization library that generates e.g. JSON codecs at compile time. Not sure if that fits the bill.

Looks like it's doing annotation processing at compile time? The trouble with that is that you end up with "magic" code like calling methods that don't appear to exist, and in order to be able to work on the serialisation itself (e.g. to add a new format) you have to understand the "magic", because there isn't a good intermediate abstraction. The great advantage of Shapeless is that all the "magic" is in the library itself and it spits out a generic representation of your data classes in record form; you can implement a new serialisation format in 100% vanilla Scala without having to worry about any macros or annotations or anything.

Re: New Features in Java 14

#74

Post by riquito » Wed, Mar 04, 2020, 5:00 AM UTC

jeswin wrote: post #71

Benjammer wrote: post #53

Earlier quoted context omitted.

You'd probably have to manually write a Builder in the Person record class. Then the callsite might look something like this: val emily2 = emily1.newBuilder() .lastName("Wells") .age(26) .build() I think the inner Builder pattern is common enough in immutable java object implementations that they might want to include that fully in the Record class generation at some point. Most immutable object libraries that I've s…

Why not do what JS does? val emily2 = { ...emily1, age: 30 }; This has many advantages, one being that it provably and declaratively creates a copy, which is not the case with the builder. In fact the obsession with methods (and hence the implied state) is what makes Java a terrible misfit for functional paradigms such as immutability.

JS is not any better in that regard, that simple example is ignoring nested objects, where the outer one is copied and the inner are referenced (unless you use triple dots all the way down - tedious and error prone, or even simply inefficient if done by some recursive algorithm). The syntax is cool though

Re: New Features in Java 14

#75

Post by Yhippa » Wed, Mar 04, 2020, 5:08 AM UTC

smt88 wrote: post #37

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?

I would be the only one on my team who would be using Kotlin. I didn't know that Kotlin had that though.

Re: New Features in Java 14

#76

Post by swsieber » Wed, Mar 04, 2020, 5:09 AM UTC

baddox wrote: post #21

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 wouldn't quite phrase it that way, since it's nothing new. OCaml from the 1990s has no null value (you need to represent potentially missing values with Option). I suspect there are older examples than that.

I would tentatively phrase it like that. It's not that rust is original in that regard, but instead effective though actually being adopted.

Re: New Features in Java 14

#77

Post by pix64 » Wed, Mar 04, 2020, 5:10 AM UTC

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…

Option explicitly states the value may be none.

Re: New Features in Java 14

#78

Post by sa46 » Wed, Mar 04, 2020, 5:11 AM UTC

jeswin wrote: post #71

Benjammer wrote: post #53

Earlier quoted context omitted.

You'd probably have to manually write a Builder in the Person record class. Then the callsite might look something like this: val emily2 = emily1.newBuilder() .lastName("Wells") .age(26) .build() I think the inner Builder pattern is common enough in immutable java object implementations that they might want to include that fully in the Record class generation at some point. Most immutable object libraries that I've s…

Why not do what JS does? val emily2 = { ...emily1, age: 30 }; This has many advantages, one being that it provably and declaratively creates a copy, which is not the case with the builder. In fact the obsession with methods (and hence the implied state) is what makes Java a terrible misfit for functional paradigms such as immutability.

I don't understand what you mean by provably. The Java example does the exact same thing as the JS version: create a shallow clone with a different age. Do you mean the builder might do something different?

    // Java
    val emily2 = emily1.toBuilder().age(30).build()

As far as adding the spread operator to Java, I think you'd have to require a Spreadable interface to use it or limit usage of the spread operators to records. It's not clear to me that the expressive power is worth it over a builder.

Re: New Features in Java 14

#79

Post by eklavya » Wed, Mar 04, 2020, 5:19 AM UTC

julius_set wrote: post #50

Would be great if Records were actually bonafide value types lol as in not allocated on the heap. Otherwise it’s just nice syntactic sugar like data classes in Kotlin

All in good time, value types is in progress. Available to try here: https://wiki.openjdk.java.net/display/valhalla/Minimal+Value...

Re: New Features in Java 14

#80

Post by wereHamster » Wed, Mar 04, 2020, 5:39 AM UTC

> Pattern Matching for instanceof

Why is the cast even necessary? Isn't the cast only part of the type checker and thus unnecessary with a smarter type checker? For example TypeScript can do it, if you have code following an if condition that checks the type of the variable, you can use that said variable as if it were of that type without any further assertions necessary, eg.

    let x: unknown;

    if (typeof x === "string") {
      console.log(x.charCodeAt(0));
    }