[records] Spec for next version of Record Classes JEP

[Remi Forax]

----- Mail original -----
> De: "Tagir Valeev" <amaembo at gmail.com>
> À: "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 20 Octobre 2020 05:08:53
> Objet: Re: [records] Spec for next version of Record Classes JEP

> Hello!
> 
> I still feel that there should be a compilation error if record
> component annotation is ineffective due to explicit specification of
> accessor method and/or non-compact canonical constructor and
> completely support Remi's argument.
> 
>> [I am expecting that most developers in this case would have added the
>> RECORD_COMPONENT target, so the annotation does not disappear completely.]
> 
> I should also note that it's hard to add a RECORD_COMPONENT target to
> the library annotation if it's intended to be used with earlier Java
> versions (don't tell me about multi-release jars!) And the semantics
> of RECORD_COMPONENT target is not very clear, as clients work directly
> with constructors and accessors (call them), but they don't work with
> record components. For most of the clients, the record is not very
> different from the ordinary class, and I'm not sure that all the
> clients should check if the called method is a record accessor, find
> the corresponding component and check its annotations, in addition to
> checking the method annotations in the first place. Also, I expect
> that people will sometimes convert records to ordinary classes (e.g.
> suppose that at some point it becomes desired to have a private
> mutable field to cache something). In this case, they can mechanically
> translate the record to the class (IntelliJ already provides this
> facility) but the annotation will disappear completely.

Obviously, I agree with Tagir.

Conceptually, the annotation propagation is a dangerous idea but we hope a lesser evil.

We fundamentally don't need annotation propagation, it's a nice to have to accelerate adoption of records, libraries that read annotations and annotations itself may not need to be updated to use records because we propagate annotations. But it comes with a price, the annotation propagation mechanism is implicit, so most people will not be aware of that mechanism, after all they put the annotation on the record components not on something else. 

Given it's an implicit algorithm our users may be not aware, it should not fail silently.
If people are able to declare an annotation on a record component, either it works or it does not. But having a weird third state, it's useless, is bad design in my opinion.

> 
> Well, if all of this is not convincing, let's stop this discussion. I
> filed an enhancement request for IntelliJ to report the warning in
> this case:
> https://youtrack.jetbrains.com/issue/IDEA-253317
> For our users, this will be enough (after all, anyone may set a
> severity level to 'ERROR'). Other IDEs may also do the same.

IDEs can help but if JetBrain goes bankrupt one day, i hope we will still able to use Java. 

> 
> With best regards,
> Tagir Valeev.

Rémi

> 
> On Mon, Oct 19, 2020 at 11:35 PM Gavin Bierman <gavin.bierman at oracle.com> wrote:
>>
>> Following the announcement of JEP 395 [1] the latest version of the spec is now
>> available at:
>>
>> http://cr.openjdk.java.net/~gbierman/jep395/latest/
>>
>> This covers the various bugs in an earlier draft that have been reported on this
>> list. As per my earlier email this spec does not treat a non-propagating
>> annotation in the case where an explicit accessor method has been declared as a
>> compile-time error. I still think this is a better design, but if anyone feels
>> strongly, please email the list!
>>
>> Thanks,
>> Gavin
>>
> > [1] https://openjdk.java.net/jeps/395