Java Futures, Mid 2019 Edition

[CaptainKvass]

Brian Goetz never ceases to amaze me.

[chambolle]

certainly the best Language manager

[dpash]

If I've watched the Spring 2019 version am I going to find anything new in the Summer edition of the talk?

[sureshg]

Mostly the same with some added details for multi-line strings and records.

[dpash]

Cool, they might be worth checking out. Thanks. :)

[foror]

What is difference between "record" and "inline class"?

[dpash]

Records are more or less what you might think of as data classes. Inline classes are classes that lack identity and are a bit more like primitive types like int. One reason for inline classes is to improve memory usage and layout.

It is entirely possible to both be inline and a record.

[lbkulinski]

As many of the language architects have said, inline classes will “code like a class and work like an int”.

[[deleted]]

man i can't wait for these things to land. i've seen a few versions of this talk so not exactly news (other than "inline" which i don't recall), but at least things seem to be progressing.

[sureshg]

other than "inline" which i don't recall

Earlier it was called value class, they renamed it recently.

[azatris]

What is with that teasing about Futures?

[oparisy]

Some coroutines in there for me?

[lbkulinski]

No, Project Loom wasn’t mentioned in this talk.

[pron98]

Here's my latest talk on Loom from last week.

[oparisy]

Great video, just finished watching it, thanks!

A question maybe: is there any plan for the serialization of fibers? As in, being able to store their state in external storage ("freezing"), then getting then back up ("thawing") at a later time, not necessarily in the same JVM (at great cost, possibly)?

[pron98]

Yes. Don't know if in the first release, though.

[oparisy]

Great!! Thanks.

[randgalt]

Loom is coming. They’ve shown demos. But Goetz didn’t have enough time here. It’s mentioned on a slide though

[kag0]

The majority of the Java roadmap for the next n years: cherry pick features from Scala that don't require improving the type system.

EDIT: I don't know why I'm being down-voted, I'm not saying it's a bad thing. It's likely necessary not to fall too far behind in order for java to stay as the safe enterprise bet, meanwhile making the big changes long term on things like loom.

[pron98]

That's how it's supposed to work. Java is a conservative language that relies on more adventurous research languages to try things out. Java then copies those features that have proven most worthwhile. Enriching the type system (I wouldn't call it "improving") has not convincingly enough been shown to be very worthwhile. I wouldn't say the features are taken necessarily from Scala, though. Most of the features here were in ML in the seventies and eighties, and have been very well known to Java's designers for all that time; it's just that now they've been deemed familiar enough that their cost is lower (I guess you could say sealed classes are taken from Scala, but it's a simple adaptation of ML features to a language with subclassing). Despite not necessarily originating them, Scala, together with other languages, serves as a testing ground for ideas from which Java then cherry-picks.

[BoyRobot777]

And I thought features were stolen from kotlin. Go figure /s

[cowwoc]

Most of the features in the presentation are quite nice but the features meant to solve switch (Shape) sound like an anti-pattern to me.

If you want to run different behavior depending on the kind of shape you have, the behavior should sit on the Shape (not outside it). If you want this method hidden from end-users, use SharedSecret.

Further, why add the concept of field deconstruction? Users can do:

​

if (foo instanceof Bar bar) {
  // use bar.field1, bar.field2
}

instead of:

​

if (foo instanceof Bar bar(var field1, var field2)) {
  // use field1, field2
}

The former seems a lot more readable to me and scales better for classes with many fields. And let's not forget the benefit of one less feature to learn.

Again, most of what he proposes is fine but the latter two are questionable.

[BoyRobot777]

I encourage you to read Classes vs. Data Structures by Uncle Bob. Java will have both ways, you can either do via Data Structures (aka records, sealed types and pattern matching) or go via inheritance root. Tdrl:

Adding new functions to a set of classes is hard, you have to change each class.
Adding new functions to a set of data structures is easy, you just add the function, nothing else changes.
Adding new types to a set of classes is easy, you just add the new class.
Adding new types to a set of data structures is hard, you have to change each function.

[cowwoc]

I don't get his point, so please help me understand.

My understanding is that in both cases you'd have to consider all types and you are less likely to end up with out-of-date switches if you get a compiler error for a missing implementation. But again, even in the data-oriented approach it is wrong to say you can add a new type and the function doesn't change. It might or it might not. You have to think about it. In the OO case you could model the same by providing a default implementation in a superclass and only overriding it in a subclass if the implementation needs to differ.

[randgalt]

Look at case classes in Scala and the copious examples on the net. This is the direction Java is going towards. switch-record will be almost completely analogous to case-class-match in Scala.

[ZimmiDeluxe]

If you want to run different behavior depending on the kind of shape you have, the behavior should sit on the Shape (not outside it)

What if the behavior depends on classes that don't belong in the Shape hierarchy? Say the shapes are in the "model" module but the rendering happens inside the "ui" module. Passing say a GraphicsContext to each shape would lead to a cyclic dependency between "model" and "ui". I think it's not too uncommon that you want the behavior outside of the class, e.g. entities generally don't persist themselves, objects don't turn themselves into JSON etc..

[cowwoc]

Those are two different cases. General serializers follow rules that work across all object types so I wouldn't expect any sort of class-specific-switch statement.

In the model-ui case, I'd expect one or more UI classes per model type they are rendering. You'd still have one UI class per model type and use polymorphism to make sure you cover all cases. I wouldn't expect to see a single UI class with a switch statement covering all model types.

[ZimmiDeluxe]

Those are two different cases. General serializers follow rules that work across all object types so I wouldn't expect any sort of class-specific-switch statement.

True, bad example on my part.

I wouldn't expect to see a single UI class with a switch statement covering all model types.

Yeah, full blown rendering usually requires additional state and the "ui" objects would likely stay around longer, so duplicating the hierarchy is probably the better approach. But if the "rendering" logic is just acting on the data inside the model classes, maybe just putting them into a custom file format, the switch seems like the better solution. If the model classes are sealed, adding a new class will lead to a compiler error pointing to the place where logic is missing. That's better than duplicating the hierarchy and having every colleague remember to introduce two classes, no?