[records] Time to re-read JEP 359

[Tagir Valeev]

Hello!

пн, 6 янв. 2020 г., 22:42 Brian Goetz <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/4e45b086/attachment.htm>