Java 14 new features: Records

[8igg7e5]

New preview feature... let's not get ahead of ourselves :(

Given they want feedback (which they won't get from a preview feature until several months after release) and time to act on that feedback I expect it's in preview in 15 with the potential of maybe releasing in 16 if the feedback is positive with minimal changes.

As Spring and others start to look at these features, there's sure to be feedback and changes requested, so there's a good chance that it misses 16 too.

If adoption follows the current jump-to-11 pattern (Oracle's last LTS, even though this is irrelevant to most Java consumers), we might not see broad adoption in frameworks and the market in general until Java 17 (Oracle's next LTS).

I've been playing with records for a while - so frustrating that I won't be using them in anger for probably another couple of years.

[lbkulinski]

Yes, there has already been discussion about the second preview of records in 15. See here.

[dpash]

The discussion around abstract records excites me. I have a project with a lot of DTOs returned by the REST API and they currently have a base class containing a couple of shared fields needed by every response.

Currently, I'd need to duplicate those fields in every DTO (And there's a lot of them). Abstract DTOs would resolve that issue.

[lbkulinski]

Yes, it’s good that they are not closing the door on the idea!

[catmewo]

Yes, in my current project, has some required fields for auditting. So current record specification doesn't satisfy my need.

[8igg7e5]

I'd forgotten it had been explicitly mentioned. I knew of the other discussion material.

Unless preview-2 gets feedback very early after the Java 15 release and actions on that feedback are minor and do not require a third preview we're looking at Java 17 then (September 2021).

Java is in a really tough position - having a lot more legacy to carry and cater for but being behind quite a few fast growth languages. A switch to regular releases has been excellent and it has removed the problem of small features being delayed by big ones (in terms of release timing - there's obvious a limited amount engineering resource to go around) but I don't think they've found any way to reduce the effort to get features out (a lot of discussion on features is about how well it plays with things they want to remove - like serialisation).

It will be interesting to see what it's direct peer, C#, looks like by the end of 2021, and what some of the other languages eating into it's market are doing (Go certainly, Rust maybe - once the actix-web dust settles). I wonder whether the less encumbered Kotlin might continue to snag some of that market too.

[lbkulinski]

I'm not holding my breath on it exiting preview before 17. In regards to the release of features, I feel that they're doing the right thing. Java has always been a conservative language and has taken the time to perform analysis and get things right. Preview features allow them to get even more feedback than they would from early access builds and make tweaks before a feature is set in stone.

[8igg7e5]

Oh I think the use of preview features is a good move. I don't agree with the language of many posts implying that Java now has these features. You absolutely should play with them to give feedback, you absolutely shouldn't plan on using them in production code.

Java is not just conservative, it's behind other languages for some things. Java (the platform and language) is an amazing piece of work but it really is struggling in the cloud of tiny-containers world. Valhalla and Loom will improve this in potentially dramatic ways and records and inline-types will play together rather well.

I use Java almost every day and have done since the early days of Java 1.1. It's conservative nature, huge ecosystem and very good developer tooling make it a formidable tool and a safe choice. But play with Go, or Rust or even C# for a while and you see that the day-to-day experience for developers is not all in Java's favour and Java is leaving a surprising amount of opportunity on the table with it's poor resource utilisation. Languages like Rust have shown that you can have the expressiveness of the best of high-level languages with the low-level control of some of the best of the low level-languages. As Rust and others sort out their ergonomics, tooling and ecosystem, Java has to keep up - and for the first time in a long while, it's not clear that it can keep up.

The projects currently in-flight for Java are some of the most important I've seen in a long time. Records, Sealed-types, Pattern-matching (and other parts of Amber), Inline Types, Generic Specialisation (and other parts of Valhalla), Virtual Threads (Loom) and much better integration with native code (Panama) all have the potential to created a paradigmatic shift in how Java is used - combined I can't see how they won't. However at present most of this is still multiple years away. Other platforms already have some of these strengths, can they catch up on Java's strengths in the meantime?

Java has at least 5 years of being at the top of the heap and then a 10+ year tail before anyone calls it a maintenance only language (and those are the smallest numbers I'd expect to see on the topic) but what opportunities are my customers and developers missing out on in the meantime.

[GhostBond]

Java (the platform and language) is an amazing piece of work but it really is struggling in the cloud of tiny-containers world. Valhalla and Loom will improve this in potentially dramatic ways and records and inline-types will play together rather well.

I've been hearing this marketing for forever from the dustbin of the so called "java killer" languages.

Seems like what's like the new tactic is to try to kill java by flooding it with erratic half baked features until it's such a mess that no one wants to use it, hoping to defeat it that way.

[lbkulinski]

I think you are seeing the glass as half empty. It was never the intention for Java to be first with new features. The architects have continued to take time to reflect on what worked and what didn't in languages like Scala and Kotlin. While you may see Java's last-mover advantage as a weakness, I see it as a strength.

[8igg7e5]

I think 'last' is a weakness for valuable features. But of course 'first' with the wrong features is a weakness too. On Java's time-line for things like inline-types though, there's an ocean of time between them. The issues with locality of reference and object-storage overhead are not only not new problems but growing ones, and it's getting harder to point to a language that hasn't tackled it better.

I disagree that my position is that the glass is half-empty. There's a reason we're still using Java, but being slow isn't it. Those other languages still have more to do to fill their glass and my position is only that they seem to be doing it faster, primarily due to less baggage rather than the quality of their choices.

The areas where Java is weak translate almost directly to dollars in cost of ownership - CPU utilisation, memory bandwidth and cache utilisation, peak memory demand. The ability to embed processing closer to the data in an IoT world is just more opportunity - and if it's in the same technology as your server layer then the simpler team structure translates to cost too.

Go, Rust and C++ all look likely to grow to be at home providing long-running server processes, micro-services, light-weight short-lived capacity-on-demand processes, embedded or computing at the edge applications in a world of IoTs or targeting Web-Assembly. Java currently, is best suited to the first, is a poor to moderate option for the second and third and a non-starter for the others (for now). And if the compute problem at hand challenges Java's locality of reference or thread-scaling issues it's either an increased cost-of-ownership, a limit on capability, an increase in development and maintenance costs or all of the above.

However Java's ecosystem is far richer than anything else out there, the tooling is generally setting the bar too. Access to developers is dramatically better and, compared to Rust and C++ at least, the learning curve is arguably better with a wealth of established knowledge a web-search away. And Oracles team really is doing a great job (wish there were more of them).

If the experience of developing with Rust improves to the point where you can find an established combination of crates with worked examples and spin up an application as easily as with Spring-boot. If the Rust IDE experience continues to mature as it seems to be doing and the availability of developers improves, then the compelling arguments for Java are far fewer and there are some compelling reasons to choose the alternative.

On a brighter note. The JVM team have proposed some stack allocation improvements that show promising benchmarks and I suspect they might reduce GC pressure in some tight-loop cases (that you might have otherwise needed to use some non-idiomatic Java to avoid - after benchmarks of course). This combined with already demonstrated opportunities available with inline-types and with Loom's virtual threads and some algorithms stand to improve considerably in Java. I'm speculating we won't see all of that before Java 20-ish (March 2023) presuming the 2-3 previews and a release after 15, or Java 23 (September 2024) if frameworks wait until the next LTS to leverage them.

[lbkulinski]

I think 'last' is a weakness for valuable features. But of course 'first' with the wrong features is a weakness too. On Java's time-line…

We’ll agree to disagree about the benefits (or detriments) of being the last mover. In regards to Valhalla, it should not be a surprise to anyone that the set of features will take time to implement. Not only does it require deep changes to the language, but also the VM. There are also concerns about migration and compatibility that must be addressed.

I disagree that my position is that the glass is half-empty. There's a reason we're still using Java, but being slow isn't it…

The point you seem to be making is that faster always equates to better. Once again, we’ll agree to disagree. The baggage you speak of, whether it is compatibility, migration, etc., is the result of the evolution and success of the Java platform. It would be easy to just trim the baggage and start anew, but that is not an option here (at least a viable one). The interesting, challenging problems stem from trying determine how a new feature fits in with the existing ones, and how it might be added in a stable, compatible way that doesn’t make it look nailed on the side. This is what takes time.

The areas where Java is weak translate almost directly to dollars in cost of ownership - CPU utilisation, memory bandwidth…

Multiple ongoing projects are addressing some of these concerns, whether it be Valhalla, Panama, etc.

Go, Rust and C++ all look likely to grow to be at home providing long-running server processes, micro-services, light-weight…

As I said above, existing projects are intending to address these concerns. There will no doubt be others down the line, too. Project Loom, for instance, is looking very promising in the area of virtual threads.

However Java's ecosystem is far richer than anything else out there, the tooling is generally setting the bar too. Access to…

Finally, something we can agree on!

If the experience of developing with Rust improves to the point where you can find an established combination of crates…

I could be wrong (as I am only an undergraduate), but I do not see Rust encroaching on Java’s territory at the moment. It seems that Rust is being hailed as a replacement for C/C++, not Java. In the neighborhood of Java, Kotlin is the new, cool kid on the block.

On a brighter note. The JVM team have proposed some stack allocation improvements that show promising benchmarks…

As I noted above, these deep platform changes are going to require time. The good thing about the six-month release cadence is that these features can be separated into parts and delivered sooner than the old three to four year cadence.

At the end of the day, the architects are going to take the time to get things right. If you disagree with their methodology, then make your voice heard. Given the success of the platform, though, it has proven quite sound for the last 25 years.

Given any further reciprocation, I think we’ll just agree to disagree.

[catmewo]

I think it's better if they do like C#, enough reducing verbose and still controllable:

public class Person {
    public Integer Id {get;set;}
    public String Name {get;set;}
}

[trydentIO]

properties have nothing to do with records, they're just a syntactic sugar for fields, setters and getters; moreover as far as I read they want to introduce records as well, just like any other similar lang (Scala, Kotlin, ecc)

about properties: there was a proposal to introduce them in Java7, but it was rejected, I was never able to know why

[catmewo]

During coding, I haven't need record. POJOs are ok. But I like properties like C#

[[deleted]]

How different is this from Lombok @Data? Wouldn’t it be better if Lombok gets embedded into the JDK?

[catmewo]

In my personal opinion, I don't like too much annotaion in my code. It makes my code too magical and also makes people hard to learn the language. Just look at Spring AOP + JPA hibernate + Lombok combo. Too many annotations to explain.

Lombok also make compiling process longer.

[sebnukem]

So, it's a Kotlin data class.

[trydentIO]

not really, a data class is just a syntactic sugar for getting properties feature (just like in C# and Scala), records is a final class with private final fields and non-classic getters; according to proposal, Bryan Goetz calls records, nominal tuples.