Records -- Using them as JPA entities and validating them with Bean Validation
Brian Goetz
brian.goetz at oracle.com
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
inheritance.
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