[records] Time to re-read JEP 359

Brian Goetz brian.goetz at oracle.com
Mon Jan 6 16:15:41 UTC 2020

I mostly agree.  For the "record", here's one more possible reason I 
left out:

  - So you can put Javadoc on the fields.

Again, I don't find this one particularly compelling, but I wanted to 
put it in the record.

On 1/6/2020 11:10 AM, Tagir Valeev wrote:
> Hello!
> пн, 6 янв. 2020 г., 22:42 Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>>:
>       - Maybe the author wants annnotations on the fields that, were
>     they to
>     be put on the components, would be spread to places where they are
>     _not_
>     wanted.
>     The last of these is the only one that is mildly compelling here,
>     but, I
>     wonder whether this is purely theoretical, or whether someone
>     actually
>     needs this.
> I'm for not allowing this. I cannot imagine that custom annotation 
> could be necessary. I saw many kinds of annotations but I don't think 
> there's some scenario when it's necessary to annotate a private field 
> of record and it cannot be covered by the corresponding annotation of 
> record component or explicit accessor. Many annotations simply don't 
> applicable to record fields. E.g. dependency injection like @Inject or 
> @Autowired: this should be done via canonical constructor instead of 
> reflection. Or Lombok's @Getter (who needs Lombok getters in record?), 
> @Setter (field is final, no setter is possible). JPA injections are 
> also should be done via the constructor, so record component 
> annotation should be better. Static analyzer suppression annotations 
> are also unlikely necessary: what could be suppressed for implicitly 
> defined fields?
> Well, it could be desired for nullability, e.g.:
> record ListWrapper<T>(@Nullable List<T> list) {
>   public ListWrapper {
>     this.list = list == null ? List.of() : list;
>   }
>   public @NotNull List<T> list() { return list; } // IDE might warn 
> here that you are returning nullable field from a method marked as 
> not-null.
> }
> In this particular case, it could be desired to specify an 
> explicit @NotNull on the field. However, this could be solved 
> defaulting to @NotNull instead:
> record ListWrapper<T>(@NotNull List<T> list) {
>   public ListWrapper(@Nullable List<T> list) { // need to specify args 
> here, but no need to override accessor method
>     this.list = list == null ? List.of() : list;
>   }
> }
> Even though we cannot use a compact constructor anymore, this looks 
> clean solution to me.
> In any case, we can allow it later if somebody comes up with an 
> example where it's really necessary.
> With best regards,
> Tagir Valeev.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200106/ebad25f7/attachment.htm>

More information about the amber-spec-experts mailing list