[records] Specify use of @Override and @SafeVarargs on record components

Brian Goetz brian.goetz at oracle.com
Wed Jan 22 15:35:16 UTC 2020

Nice catch, Tagir.  Historically the @Target meta-anno has been strong 
enough to keep people from putting annos in the wrong place, but with 
the "clever" handling of annos with records (accepting any of the target 
types an anno can be reasonably pushed down to), we don't have any way 
of saying "except these, which make no sense."

I agree it is silly to put these annos on record components. On the 
other hand, I am not sure the spec should prohibit them -- seems more 
the sort of thing an IDE should say "hey, that was probably dumb, are 
you sure you want that?"

In any case, it is reasonable for a compiler to error in the case of 
@Override on a component whose accessor does not override something -- 
because we should type-check implicit members as well as explicit.

On 1/22/2020 3:03 AM, Tagir Valeev wrote:
> Hello!
> It appears that it's possible to annotate record component as
> @Override or @SafeVarargs, and spec doesn't explicitly forbid this:
> record Test(@SafeVarargs int x, @Override int y) {}
> In these cases, it's assumed that the annotation propagates to the
> accessor method. However, having @SafeVarargs on the accessor method
> is prohibited, so should be in a record component. So I expect to see
> in something like this:
>> It is a compile-time error if a record component (§8.10.1) is annotated with the annotation @SafeVarargs.
> Having the @Override is possible on the accessor if accessor overrides
> the interface method (and it's really cool possibility!) Probably it's
> ok to allow this annotation on the record component in this case, but
> it should be definitely disallowed if the accessor doesn't override
> anything. So I expect something like this in
>> If a record component (§8.10.1) of record R is annotated with the annotation @Override and the accessor method for that component (§8.10.3) does not override a method declared in a superinterface of R (§, then a compile-time error occurs.
> What do you think?
> With best regards,
> Tagir Valeev.
> [1] https://docs.oracle.com/javase/specs/jls/se13/html/jls-9.html#jls-
> [2] https://docs.oracle.com/javase/specs/jls/se13/html/jls-9.html#jls-

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

More information about the amber-spec-experts mailing list