Java 14 Feature Spotlight: Records

https://www.infoq.com/articles/java-14-feature-spotlight/?

by chhum • 6 years ago

204 148 6 years ago

These seem extremely similar to Scala's case classes. In my experience, case classes are often the feature that sells people on moving over to Scala from Java (the other being exhaustive pattern matching warnings from the compiler).

Fingers crossed Java never implements the `implicit` keyword...

McDev• 6 years ago

And Kotlin data classes: https://kotlinlang.org/docs/reference/data-classes.html

q3k• 6 years ago

... all of these are likely inspired by the extremely powerful namesake of Java Records: Haskell Records [1].

[1] http://learnyouahaskell.com/making-our-own-types-and-typecla...

harryh2• 6 years ago

The implicit keyword is extremely powerful when used appropriately and not something that should just be shunned completely.

My favorite usage is probably in a typesafe Query engine that several people[1] built at Foursquare that is a lot better than what you can find in the java world.

  Venue.where(_.closed eqs false)
       .orderAsc(_.popularity)
       .limit(10)
       .modify(_.closed setTo true)
       .updateMulti

It allows for all sorts of typesafe queries that will fail at compile time if things are malformed including stuff like failing to query on an index.

https://github.com/foursquare/rogue

1. Hi Jorge, Liszka & Neil!

dangerlibrary3• 6 years ago

I've never shown a use of "implicit" to an experienced developer unfamiliar with Scala and seen them get excited about the language.

The best case scenario is that they aren't instantly horrified / confused / repulsed.

Joeri• 6 years ago

I only see a superficial similarity. Case classes are much more powerful. Copy constructor, private constructor, pattern matching, overrideable apply/equals/hashcode. Granted, some of that stuff is esoteric, but it does make case classes a very different beast.

halfmatthalfcat• 6 years ago

Implicits are very powerful when used tastefully but are being replaced/deprecated in Scala 3 regardless.

virtualwhys• 6 years ago

Actually, implicits aren't going anywhere in Scala 3.

There will be new syntax, but otherwise the underlying semantics will remain the same; it's just the implicit keyword itself and the kitchen sink of functionality that it provides in Scala 2 will be split up into new (soft) keywords like "given foo(using: Bar) = ..." rather than "implicit def foo(implicit bar: Bar) = ...", along with "extension listOps of" replacing "implicit class ListOps ...".

The community isn't united over the proposed changes (mostly due to migration concerns it seems), but overall it looks like a nice improvement over the status quo, particularly around typeclass definitions.

ecoffey• 6 years ago

re: implicits... https://twitter.com/ecoffey/status/1179198362924404736?s=21

LordHeini• 6 years ago

I would say there are tons of other features as well.

More often than not Java programming just consists of throwing gang signs on your keyboard for your Ide to create tons of boilerplate.

Well case classes can implement traits, might have a companion object and can (poorly) replace enums.

Scala sometimes seems to not need standard classes.

Other languages like go, rust or c can do just fine without classes at all.

th0ma5• 6 years ago

This sounds a lot like Clojure records and it may be some time before I can mentally distinguish them just based on the name alone.

hyperpallium6• 6 years ago

They're not really "tuples", but classes with auto-boilerplate. e.g. you can't say:

  (x,y) = getXY();

instead

  record Coord(int x, int y) {}
  Coord coord = getXY();
  // access as coord.x, coord.y

It's not terrible, but it's terribly javay.

frou_dh2• 6 years ago

That's more lack of destructuring syntax than non-tuple-ness, no?

hyperpallium6• 6 years ago

I think both.

kasperni6• 6 years ago

That is by design (https://cr.openjdk.java.net/~briangoetz/amber/datum.html)

Why not "just" do tuples?

Some readers will surely be thinking at this point: if we "just" had tuples, we wouldn't need records. And while tuples might offer a lighter-weight means to express some aggregates, the result is often inferior aggregates.

Classes and class members have meaningful names; tuples and tuple components do not. A central aspect of Java's philosophy is that names matter; a Person with properties firstName and lastName is clearer and safer than a tuple of String and String. Classes support state validation through their constructors; tuples do not. Some data aggregates (such as numeric ranges) have invariants that, if enforced by the constructor, can thereafter be relied upon; tuples do not offer this ability. Classes can have behavior that is derived from their state; co-locating state and derived behavior makes it more discoverable and easier to access.

For all these reasons, we don't want to abandon classes for modeling data; we just want to make modeling data with classes simpler. The major pain of using named classes for aggregates is the overhead of declaring them; if we can reduce this sufficiently, the temptation to reach for more weakly typed mechanisms is greatly reduced. (A good starting point for thinking about records is that they are nominal tuples.)

hyperpallium6• 6 years ago

The major pain of using named classes for aggregates is the overhead of declaring them

But the pain remains the same in client code. Because api's are written once, but used many times, it is more important to make client code simple than api code.

In mathematics and programming, tuple content is accessed by position, not by name. e.g. The arguments in method/constructor invocation form a tuple - so there is precedent, even within java itself. Note that callers (clients) address arguments by position, and callees address them by name (api's).

There'a a very similar passage in the article to the one you quoted. Regarding nominal vs structural there, a better example is that java's class system is nominal.

"records" are nominal in that they have a class-like name, and also their content is accessed by name. Tuples are structural (not named), and access by position (not name). So I think records are not really "tuples".

abraxas4• 6 years ago

Will arrays of records be contiguous in memory or are we still chasing pointers just as with all other arrays of objects in Java?

kasperni6• 6 years ago

Records can be combined with inline types when they get there with project Valhalla.

chris_overseas• 6 years ago

You'll still be chasing pointers with these. What you (and myself and many others) are looking for are inline types[0][1] that are part of Project Valhalla[2].

[0] https://openjdk.java.net/jeps/169

[1] https://dzone.com/articles/valhalla-lw2-progress-inline-type...

[2] https://wiki.openjdk.java.net/display/valhalla/Main

abraxas4• 6 years ago

Thanks, you're right on. That's what I'm after and that's exactly what Java needs to be useful for doing high performance computations in a sane fashion.

BubRoss3• 6 years ago

Does it strike anyone as odd that something trivial in toy languages from the 70s is a separate project 30 years in and named for the the heaven of the gods in the world of Java?

dajohnson892• 6 years ago

I always thought array elements were contiguous in memory? Is it that the objects are contiguous, but the pointers are not? If so, this does seem pretty expensive and I wonder if there's any workarounds.

cies3• 6 years ago

Records can be used in a wide variety of situations to model common use cases, such as multiple return [...]

I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure (Either in Haskell, Result in Kotlin and Rust).

This type of type is a sum type a.k.a. a tagged union, you could think of as Enum types where each item can have a payload.

This comes in really handy and allows Kotlin not to (ab)use exceptions for non-fatal errors.

I never had the problem with returning several objects at ones, I would simply write a class that embeds them (and in J14 I can write a record).

Someone• 6 years ago

”I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure”

That’s or (another) one in case of failure, and not multiple return values. It returns a single value.

”I never had the problem with returning several objects at ones, I would simply write a class that embeds them”

One man’s “simply” is another man’s “ugly boilerplate” or “unnecessary production of garbage objects”.

You could similarly ”simpler write a class that embeds either of them”, like this:

   class AorB {
     private final Boolean itsAnA;
     private final A a;
     private final B b;
     public AorB(A aa) {
       a = aa;
       b = null;
       itsAnA = true;
     }
     public AorB(B bee) {
       a = null;
       b = bee;
       itsAnA = false;
     }
     ...
  }

Ugly boilerplate? Yes. Not optimally efficient? Yes. Not as nice as the real thing? Yes. Workable? Yes. Good idea? Debatable. Java culture would use an exception if B is an error type.

cies3• 6 years ago

I wonder what the "match" statement would look like on your example. This is exactly as you say though: ugly, inefficient, not-as-nice, yet works. And clearly debatable, especially as it goes against Java culture.

The pattern could be used commonly, and clean-up heaps of code, and remove exception's hard-to-wrap-yr-mind-around flow jumps/etc, that I do hope for both tagged unions and match switches on them to be introduced. Some are already demo features IIRC.

masklinn3• 6 years ago

I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure (Either in Haskell, Result in Kotlin and Rust).

That's not a "multiple return", that returns a single value which is either one type or the other. Although some languages do implement it via MRV by necessity (e.g. Common Lisp, Go, Erlang).

cies3• 6 years ago

I dont understand the "proper use" for MRVs then. Okay we get nicer types, record types, to do them; but they are otherwise perfectly doable and with little ugly boilerplate using classes.

The "either values", or sum types/ tagged unions I mentioned, are the thing that Java really lacks (and because of that the exception system got heavily abused IMHO).

sullyj32• 6 years ago

Technically it's not even one type or another, eg in Rust, Some(1) and None are values of the same type, Option<i32>. What's different is the tag of the enum, or the data constructor, or whatever you want to call it.

GiorgioG• 6 years ago

C# has been waiting on record types for a while.

https://github.com/dotnet/csharplang/blob/master/proposals/r...

Come on guys!

llcoolv4• 6 years ago

I am quite disappointed - if Java is supposed to compete with Kotlin, they should not just provide an inferior clone of Kotlin features, but push it a step further. Here, it is not the case as those records are basically Kotlin data classes, but not really well thought out.

Unfortunately since Oracle took over, Java as a language went in a very dull direction.

kasperni6• 6 years ago

You do know that the concept of records/data classes goes back long before Kotlin?

And what exactly are you missing?

llcoolv4• 6 years ago

When it comes to popular languages on the JVM, it doesn't go before Kotlin as Scala was never a popular language to begin with.

One thing I and a lot of people are missing is annotations, with them data classes in Kotlin are useful for JPA/REST/AMQP/etc DTOs. Another convenience would be the ability to add at least mapping methods like in Kotlin or implement interfaces (Serializable anyone?)

Java records are going to be yet another barely used feature.

pjmlp2• 6 years ago

Kotlin fans keep forgetting that without the Java platform, meaning the JVM, standard library and Maven central, Kotlin would be a non-starter.

No guest language ever took over a platform.

joshlemer• 6 years ago

It might be argued that Elixir is more popular than Erlang these days.

jfengel• 6 years ago

Doesn't adding a "record" keyword break a lot of existing code? It wasn't a keyword as recently as JDK 8 (https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...).

chrisseaton4• 6 years ago

Can you give an example of some code it'd break?

At what points in a valid legal Java program could you have previously written record, where it would now conflict with this keyword in the locations where it is valid?

Macha3• 6 years ago

Unless the rules of keywords have changed:

Map<String, String> record = getSomeData();

This should no longer be valid if record is a keyword?

kasperni6• 6 years ago

The keywords you refer to in your link are all "classic" keywords. The last one that was added was "assert" with Java 1.4, which broke a lot of code. And made people realize that adding new "classic" keywords was a bad idea.

Now, Java only adds contextual keywords. Which are basically a sequence of Java letters that are tokenized as a keyword in certain contexts but as an identifier in all other contexts. var, record, inline, module, ect. are examples hereof.

You can read more about it in this JEP Draft about "keyword management for the Java Language": https://openjdk.java.net/jeps/8223002

fctorial2• 6 years ago

It shouldn't be that big of a deal. Renaming is easy as pie in java codebases.

cletus• 6 years ago

So some immediate thoughts:

1. Why not just call these "structs"? Everyone knows what a struct is. Also making "struct" a reserved keyword is less likely to cause issues than "record";

2. I get that these are trying to be simple but why can't I compose records from other records? I guess I can have a record member of a record?

3. I couldn't see if records can be passed entirely on the stack like primitive values can. This would be huge. I seem to recall there was some effort to add this to Java but I'm not sure whatever happened to that. It probably added a ton of complexity.

Polyisoprene• 6 years ago

They are not that similar to a struct in C in that they are not just about being a data carrier. So that might be confusing if that is what you expect.

Future work is intending to solve the third point and add deconstructing the record for pattern matching.

“We can declare a simple x-y point abstraction as follows: record Point(int x, int y) { } which will declare a final class called Point, with immutable components for x and y and appropriate accessors, constructors, equals, hashCode, and toString implementations.”

kasperni6• 6 years ago

1. Records are reference types (heap allocated), structs are not. C# have structs and will also be getting records with 9.0

2. Yes, you can make records of other records.

3. Not yet, but Project Valhalla will be bringing inline types to Java https://wiki.openjdk.java.net/display/valhalla/Main

skywhopper• 6 years ago

What do you mean, "structs are not"? As far as I can tell, structs do not exist in Java?

buckminster• 6 years ago

C# records:

https://github.com/dotnet/roslyn/blob/features/records/docs/...

It's a struct or class but you only define the data members and the compiler auto-generates boiler plate like constructors, equality tests, etc.

xxs3• 6 years ago

Personally I have been wanting to use headerless objects for a long time (pre java7). The best available option is DirectBuffer, still.

BubRoss3• 6 years ago

Aren't classes already allocated on the heap? Why would C# need another type like that?

pvg• 6 years ago

There's a detailed Brian Goetz writeup about much of this at:

https://cr.openjdk.java.net/~briangoetz/amber/datum.html

vmchale2• 6 years ago

"record" is used in the Haskell world, for example. Also ATS.

stewbrew• 6 years ago

Ad 1: Maybe they like pascal, scheme etc. more than c?

Sharlin• 6 years ago

1. C popularized the `struct` keyword, but "record" is a more general, language-agnostic term for nominal tuple types in the literature.

2. Yes, it is widely accepted that a has-a relationship is the proper way to compose data. Using inheritance for composition is bad practice.

3. The article mentions inline classes, which is what the proposed value type feature is called these days. Presumably many or most record types will be inline if and when they're both implemented in some future Java version.

fmjrey• 6 years ago

Disclaimer: it's been a long time since I coded in Java, and I have no knowledge of this new record feature, but coming from clojure I would guess the answers to be:

1. You can't change a record after the fact because if you do it's no longer reliable, it's been tampered with :)

2. Yes, existing records only. You can always create a new record pointing to the old or any other record.

3. Hope not, would make it unpractical to handle verbose facts.

I guess clojure really twisted my mind ;)

namelosw• 6 years ago

It's not structs in C, it's more like records in Haskell.

If you have two records {a: 1, b: 2}, those are equal because they are the same.

If you have two structs {a: 1, b: 2}, those are also equal but they are separate instances that consume more space. The comparison is recursive.

It's more like how string works in Java and most modern languages with constant pools - behaves like values but only takes constant space.

smabie• 6 years ago

It’s crazy that Java is still trying to catch up to Scala, yet, Scala seems very maligned (at least on HN, my coworkers love it).

This is contraversial, but Java does not provide any value anymore. The JVM on the otherhand, is a remarkable piece of engineering, unrivaled by pretty much anything else in the space. I still can’t get over that Gosling was okay with the first Oak or Java or whatever release. But he’s a super smart guy so I assume there was a reason besides corporate pressure?

I’ve seen people on HN disagree, but we, as a profession, really deserve the most powerful tool for the job. Notation as a tool for thought, etc etc.

PS: The thesis is that complexity is bad (obviously), but power is good (a priori). Arguments against complexity are fine, but arguments against expressiveness and power are ridiculeous. Moreover, the arguments I’ve heard against power are strikingly similar to those I’ve heard against freedom, or drug legalization, or democracy. They always revolve around how other people are stupid and can’t be trusted with power/freedom/expressiveness/etc.

vips7L2• 6 years ago

In my experience scalac, scala, and sbt are some of the biggest productivity killers at my work place. Most devs loathe going into the parts of our code base that are scala (thanks Play).

The tooling for scala also is not as good as the rest of the Java world.

Justsignedup• 6 years ago

I worked with Scala fans, and with non-fans.

Fans love it because they code in VIM. Non-fans tend to have better tools and thus find Scala's tools very very lacking.

sk5t2• 6 years ago

Unlike Perl, I find that Scala encourages writing code that is quite clear and maintainable. Of course the unwise might go berzerk with symbolic method names and overuse of postfix notation, but written sensibly, Scala's compactness and avoidance of boilerplate and tricky control flow (break, continue, early return, multiple ctors, etc.) can improve ergonomics and readability.

vmchale2• 6 years ago

It’s crazy that Java is still trying to catch up to Scala,

Or Haskell etc... Plenty of languages have product types.

misja111• 6 years ago

> They always revolve around how other people are stupid and can’t be trusted with power/freedom/expressiveness/etc.

It's not the stupid that can't be trusted with Scala's power and freedom but it is those who are trying to be too clever. At least when they are working in a team.

Of course this is not only the case with Scala, but not many languages offer you so many different ways to abuse your power as Scala does.

pron3• 6 years ago

Many things that become mainstream was at one point a subject of research, but that doesn't mean that the mainstream is "trying to catch up" to research, because most of what is researched never gets good or appropriate enough to be mainstream. Comparing a language that in its manifest declared that it is "blue-collar" and would strive to only adopt features after they've been tried and tested for years elsewhere and then become familiar with a language that is a tool to try research questions and to judge them by similar criteria is very strange. Scala and Java have very different design philosophies, they are designed for different audiences, and they have different goals.

You also seem to be under the impression that more features always mean "better" and that more power always means "better." I am not sure what gave you that impression, but by most reasonable metrics neither of these is the case. Your comparison with democracy is also misused. I think you'd agree that if every person had the right to arrest anyone else or to judge and punish people, our situation would not necessarily be improved. Software, or at least the kind of software that Java is designed for, isn't written by a person but by a group of people, often a very large group of people, and over what could be decades. The goal of various restrictions is to protect the work. Finally, arguments for "expressivity" are just as ridiculous as arguments against it; these are largely matters of personal aesthetic preference.

vbezhenar2• 6 years ago

I have some issues with this feature.

1. I don't really like this immutable approach, I want setters too.

2. I don't need those autogenerated equals/etc implementations, it's just code bloat. May be it's OK to introduce some syntax to automatically generate them like `String toString() default;` but it should not be implicit.

3. It uses non-standard getter syntax. Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase? Both approaches are bad.

This feature looks very out of place in Java. I hope that it'll be removed in the next release and replaced with something more compatible with old code. I waited forever to get short property syntax in Java and got unusuable feature in the end. I don't want to migrate to Kotlin just because of properties.

_bxg1• 6 years ago

I don't really like this immutable approach, I want setters too.
I don't need those autogenerated equals/etc implementations, it's just code bloat. May be it's OK to introduce some syntax to automatically generate them like `String toString() default;` but it should not be implicit.

It sounds like you just want... regular classes? I don't understand your position here. Immutable data structures have many uses and are quite popular. If that's not what you want, why use these at all?

Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase?

C# is the same way. The getProp() convention isn't as strong because it's had computed properties for longer, but one doesn't have to preclude the other.

Rebelgecko• 6 years ago

It sounds like you just want... regular classes? I don't understand your position here. Immutable data structures have many uses and are quite popular. If that's not what you want, why use these at all?

Records provide a lot of syntactic sugar that classes don't (which is the whole reason to use them— there's nothing stopping you from creating a regular class with all final fields).

edit: I'm assuming that the "finality" of fields in records is identical to the shallow finality of a final field in an object

dmitriid• 6 years ago

It sounds like you just want... regular classes

I wish Java provided syntax sugar similar to C#'s with {get; set;} and quick initialization with

  new C {
    field1 = X,
    field2 = Y,
    ...
  }

Java is unnecessarily verbose in this regard.

Records bring syntactic sugar to records only. And you're stuck with pages upon pages of unnecessary boilerplate code for classes.

fgonzag• 6 years ago

So you don't want records, you want something else.

The rest of us who've use kotlin's data classes or similiar features in other languages really like the first two points (the third point I don't mind but I don't like it either).

krzyk3• 6 years ago

3. It uses non-standard getter syntax. Java developers used `getProp()` forever, now it's `prop()`. Shall we rewrite old classes or tools? Shall we live with two different styles in one codebase? Both approaches are bad.

This was used in the olden days, nowadays developers prefer not to use pointless words in method names.

I really like those, and it also strengthen the fact that records are not java beans. If you want those you should write a regular class.

mumblemumble• 6 years ago

I'm trying to decide how I feel about the naming convention. On the one hand, I don't want there to be two conventions for no reason. On the other hand, I think I see a reason: `getProp()` is a method that might do _anything_, up to and including making some I/O call that might fail. With a record's `prop()` call, though, I can expect that it's just getting a value. And I sure wouldn't mind having a convention that `valueName()` is a lightweight getter, whereas the 'get' in `getValueName()` is a warning to be on guard for side effects.

To the first two, it sounds like maybe you just don't want what it's offering. The autogenerated equals, etc can only work sensibly if instances are immutable. And if instances are immutable, enforcing a value-level comparison so that you can have predictable, standardized semantics around one of the pricklier bits of how a datatype is defined makes a fair bit of sense.

philjohn• 6 years ago

Why do you want mutable objects?

vbezhenar2• 6 years ago

Because they are more convenient and performant. Immutable objects have their place, of course.

dwohnitmok7• 6 years ago

Records are great. If sealed classes become a thing (https://openjdk.java.net/jeps/360) I'll be absolutely elated. And it would be just the cherry on top if the two could be used together (along with a private constructor). Scala has this, i.e. `sealed abstract case class`, Kotlin does not, i.e. `sealed data class` is not valid.

I am thrilled that algebraic datatypes (effectively the combination of records and sealed classes) are finally entering mainstream consciousness and that statically typed languages all over the place are starting to adopt them.

jillesvangurp• 6 years ago

Kotlin data classes cannot be extended and they can only extend sealed classes. So they are effectively sealed already.

dwohnitmok7• 6 years ago

I perhaps should have been more explicit about the goal rather than the method, since sealing records is only one part of this.

This is all in service of private constructors. You effectively cannot have private constructors for data classes in Kotlin because the copy method remains public and cannot be "turned off." `sealed abstract case class` in Scala gets rid of that.

Private constructors for record types is a fantastic light-weight way of incorporating runtime checks into compile-time types.

pron3• 6 years ago

That's the plan: https://cr.openjdk.java.net/~briangoetz/amber/datum.html

fctorial2• 6 years ago

At first I thought it was project valhalla merging into mainline java. Apparently this is a java language feature. Java is starting to move away from being the C of jvm. Java constructs are no longer direct mappings of jvm constructs.

tristanstcyr• 6 years ago

I think that this ship has sailed quite some time ago. For example, inner classes which were introduced in Java 4 (if my memory serves right).

lokedhs2• 6 years ago

I'm pretty sure it was in Java 1.2. That's when Swing was implemented, and I don't recall ever having used Swing without inner classes.

AzzieElbab• 6 years ago

Cool. Can't wait until java people start going crazy about profunctor optics

augusto-moura• 6 years ago

Guess everyone can dream

chaostheory• 6 years ago

Did I miss something or will this feature make it into more license friendly versions of Java? Otherwise what's the point if you have to pay Oracle extortion money?

Java 14 Feature Spotlight: Records

Related Stories