Record is an immutable class, i.e. all its fields are final. Records are implicitly final, hence as well as regular final class record can't be extended.

There are a number of restrictions imposed on records (for more details, take a look at JEP 395).

Contrary to normal classes:

• it's forbidden to declare instance fields explicitly inside records (and reminder: all fields are final, which is a very impotent distinction);
• extends clause is not allowed with records, because every record implicitly extends abstract class Record;
• record can't be declared with any of these modifiers: abstract, sealed, or non-sealed (as a consequence of being implicitly final);
• records can't declare instance initializers and native methods.

Records are meant to be "transparent carriers for immutable data" as JEP 395 says.

They are designed to be concise, default constructor, getters, hashCode/equals and toString() will be generated by the compiler for you. So that inside a record you need to declare only your custom logic (if any) and record declaration can be literally a one-liner.

Records differ a lot from regular final classes.

Also, apart from the peculiarities mentioned above, the mechanism of serialization / deserialization was reimplemented for records, so that deserialization doesn't bypass the constructor.

In which case should I use a record?

In short, if your objects must be stateful, or you need to extend a particular class, then you can't utilize record in such a case.

On the other hand, if your objects are meant just carry the data, they are not intended to be modified or inherit from other classes, then it might be a good candidate to be implemented as a record.

A final class is simply one that cannot be extended. But that imposes no other constraints on the class; it can still have mutable fields, fully encapsulate its state, etc.

A record is a transparent carrier for a given tuple of state components, and is required to expose an API derived from its state description. Records are therefore more heavily constrained, but in exchange for these constraints, you get a great deal of convenience (constructors, accessors, Object methods) as well as some semantic promises (e.g., that unpacking a record with its component accessors and repacking the results with the constructor gives you an equals object.)

Records also happen to be final classes, but this is a very small part of what it means to be a record.