Records for Annotation Values

[Brian Goetz]

You’ve got the Causality backwards. Annotation values are immutable, but that doesn’t mean any immutable quantity can be an annotation value.  (And records aren’t even immutable, they are only shallowly immutable.)

Annotation values have much stricter constraints. They need to be constant pool constants, With the exception of several types that are part of the language and that have suitable classfile encodings.  An anno value can be a number, a string, a class, an enum constant, an annotation, or an array of one of these things.

A more apt example of something we might extend annotations to support is method references. They meet all the philosophical and practical requirements, as they are symbolic references to methods, but even this would still be a significant amount of work, because it touches the class file format, the VM, reflection, etc.  So I wouldn’t hold your breath for that either, but that’s a much more realistic possibility than arbitrary supposedly immutable objects.



Sent from my iPad

On Jul 2, 2022, at 12:41 PM, Nathan Reynolds <numeralnathan at gmail.com> wrote:


If I understand correctly, records are immutable.  Annotation values require immutable values.  Can we allow records for annotation values?  What would be the problems with this?

For example, I would love for Duration to be made into a record and then Duration can be put into an annotation.

@Retry(maxAttempts = 3, delay = Duration.ofSeconds(10))

... as opposed to what is required today ...

@Retry(maxAttempts = 3, delay = 10, durationUnit = ChronoUnit.SECONDS)  // This is error prone because the value and units are separated and the reader may make a mistake

If Duration, Instant, etc. hasn't been made into a record, I realize that this might need to wait so that the classes evolve slowly.  Let's ignore that possible constraint for this discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220702/45eee90c/attachment-0001.htm>