[records] Spec for next version of Record Classes JEP

forax at univ-mlv.fr forax at univ-mlv.fr
Thu Oct 15 20:42:03 UTC 2020

> De: "Gavin Bierman" <gavin.bierman at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 14 Octobre 2020 23:19:16
> Objet: Re: [records] Spec for next version of Record Classes JEP

> 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 :-)

Maybe i'm the only old guy here but Java was once touted as the best programming language because it has no warning. 
Warnings were introduced later in Java 5, because of generics. 

> 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 think it should be an error because from a user POV it's like if the compiler silently remove the annotation behind your back. 

As an analogy, when you put an annotation in a target not listed in @Target(), the compiler emit an error, it doesn't silently remove the annotation. 

> [I am expecting that most developers in this case would have added the
> RECORD_COMPONENT target, so the annotation does not disappear completely.]

A lot of annotations already exist. 
And people writing annotations (lib developers) are really few compared to people writing records (app developers). 

> Thanks,
> Gavin


>> On 5 Oct 2020, at 05:47, Tagir Valeev < [ mailto:amaembo at gmail.com |
>> amaembo at gmail.com ] > wrote:

>> On Sat, Oct 3, 2020 at 12:09 AM Brian Goetz < [ mailto:brian.goetz at oracle.com |
>> 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.

More information about the amber-spec-experts mailing list