Records -- Using them as JPA entities and validating them with Bean Validation

Brian Goetz brian.goetz at
Mon Apr 9 22:07:24 UTC 2018

First, let me answer the questions embedded here and ask a few more:

>    * Concrete records are final: that'd prevent records to be used for
> modelling some inheritance hierarchies. While not ideal, I don't think it'd
> be too big of a problem in practice, as from what I see, oftentimes users
> try to avoid inheritance in their persistent domain models anyways

There is a notion of abstract record, but no concrete-to-concrete 

Does JPA rely on runtime-generated proxies?  If so, what does the proxy 
inject into the class?  (In any case, for proxies, finality is a problem.)

>    * Custom methods: It's not fully clear to me, whether additional methods
> would be allowed on records or not; For JPA, that'd be desirable, as users
> often add methods with entity-specific logic to their entities

Yes, there's no problem with additional methods, static or otherwise.

>    * Annotation semantics: I couldn't find any example of records with
> annotations, but IIUC, something like

There's no problem with annotations, but it's not yet clear how we would 
map annotations on record components to desugared members.  In your example:
>          @Entity record Book(@Id long id, String isbn) { ... }
would the @Id annotation go onto the field, the constructor argument, or 
the getter?  The only justifiable path I can envision would be to map to 
all of them that would be permitted by the @Target of the annotation, 
which might or might not work for your cases.

More information about the amber-dev mailing list