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

[Brian Goetz]

I think there are only two credible approaches:
  - What you suggest -- which is credible because it refuses to "pick a 
winner";
  - A new target kind for "record component".

The latter is arguably better since it isn't trying to fit a square peg 
into a round hole, but is obviously more work.  (More work for us in 
spec and reflection for us; more work for frameworks as otherwise no 
frameworks will see the annos.)

Anything else ("just put them on the fields") feels like picking one 
winning use case over another.

On 4/10/2018 1:25 PM, Kevin Bourrillion wrote:
> On Mon, Apr 9, 2018 at 1:39 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>>    * Annotation semantics: I couldn't find any example of records with
>> annotations, but IIUC, something like
>>
>>          @Entity record Book(@Id long id, String isbn) { ... }
>>
>>      would desugar into
>>
>>          class @Entity public class Book { private @Id long id, private
>> String isbn; ... };
>>
>>      For the JPA entity use case it'd be helpful to have an option to lift
>> annotations to the corresponding getters instead of the fields (as the
>> location of the @Id annotation controls the default strategy -- field vs.
>> property -- for reading/writing entity state). Similarly, Bean Validation
>> would benefit from such option.
>>
> My assumption has been that we would allow an annotation on a record
> parameter as long as it has *any of *{FIELD,METHOD,PARAMETER} as target,
> and that the annotation would be automatically propagated to each
> synthesized element it applies to. Does this sound about right to everyone?
>
>