[records] Spec for next version of Record Classes JEP

[Gavin Bierman]

Hi Tagir,

Upon reflection I think it’s best that we don’t treat this as a compile-time error, but just as the specified behaviour. The warning vs error thing is a grey area, especially in Java, but having bounced this around it seems like it has fallen (just) in the warning side of the divide. As you say, this is a great opportunity for IDEs to be helpful :-)

Just to be clear:

  @Target(ElementType.METHOD)
  @interface A { }
  record R1(@A int x) {     // Where did the annotation go?
      int x() { return x; }
  }

In this example, what I am proposing is that there is no compile-time error and the A annotation will simply not be propagated anywhere. [I am expecting that most developers in this case would have added the RECORD_COMPONENT target, so the annotation does not disappear completely.]

Thanks,
Gavin



> On 5 Oct 2020, at 05:47, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> On Sat, Oct 3, 2020 at 12:09 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> I think we're reaching diminishing returns here.
> 
> Well, to me, it's not diminishing. It's certainly a piece of code that
> will not have any effect after compilation, so it's a mistake.
> Reporting it is not that hard. Having a class/runtime annotation in
> source code that disappears completely in the compiled class-file
> without any warning sounds confusing and may cause subtle problems.
> Well, of course, we can create an inspection in IntelliJ IDEA to warn
> about these cases, and people will like IntelliJ IDEA even more, but I
> believe it's a compiler job to reject this, like Java already does
> with e.g. unreachable code.
> 
> With best regards,
> Tagir Valeev.

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