Records and annotations

John Rose john.r.rose at
Thu Jun 6 22:18:17 UTC 2019

On Jun 6, 2019, at 1:48 PM, Brian Goetz <brian.goetz at> wrote:
>> But, I’m not particularly compelled by this — I think the strategy we took for enums is mostly good enough.  So I’m voting for pure B.

Yes, I track with your reasoning.  Pure B is perfectly
fine as wherever there is a mandated translation strategy
to inform the user where (in the reflective APIs) to look
for the annotation.

You can achieve A-like effects with appropriate conventions.
For example, if I have a little library of annotations just for
record components, I can target them to fields, and look for
them in Class.getDeclaredFields, even if the fields happen to
be private.  (Right?)  I'd kind of like to call this B+-.  No new
channels or API points, but a known way to find component
annotations, by looking at the fields.

If we wanted to make things more explicit, we could incrementally
modify a plan B with A-like conventions to a plan B+ in which
there's a new annotation target for components, but it still gets
passed through the field channels.  This wouldn't require new
API points or classfile formats.  Strictly speaking a new annotation
target isn't required either, just some marker or other; another
meta-annotation, but not a target type.

The net of the above is B seems sufficient, although it also seems
necessary to specify a deterministic place to find component
annotations per se (fields, I suppose).  And if we want to do
more it's easy to add a bit meta-data with a meta-annotation,
not necessarily a target type.

More information about the amber-spec-experts mailing list