On 01/06/2021 22:28, John Rose wrote:
On Jun 1, 2021, at 7:02 AM, Brian Goetz
<brian.go...@oracle.com<mailto:brian.go...@oracle.com>> wrote:
As Alan's archaeology discovered, this flag appears to be a leftover from the
original implementation, and I could find no signs of its usage.
Note to self and other reviewers of future versions
of the JVMS: When you see proposed language like
the “unless…” of JVMS 4.7.17, remember today's
conversation and try to avoid putting dark corners
like that into the JVMS.
The RuntimeInvisibleAnnotations attribute is similar to the
RuntimeVisibleAnnotations attribute (§4.7.16), except that the annotations
represented by a RuntimeInvisibleAnnotations attribute must not be made
available for return by reflective APIs, [[WE SHOULD HAVE STOPPED HERE]] unless
the Java Virtual Machine has been instructed to retain these annotations via
some implementation-specific mechanism such as a command line flag. In the
absence of such instructions, the Java Virtual Machine ignores this attribute.
https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html#jvms-4.7.17
Hi,
I do think this option, in current form, is useful as an escape hatch
for exactly the case that Jaroslav has. Java/JVM as a late-binding
runtime does a very good job of keeping the information from source
files local in direct compilation artefacts which facilitates separate
compilation where changes to and recompilation of one source file have
immediate effect on the whole app. There are exceptions to the rule such
as compile-time constants, ... and also annotation uses where the
information from one source file (annotation retention) is baked into
compilation artefacts of other source files (RuntimeVisibleAnnotations
vs. RuntimeInvisibleAnnotations). PreserveAllAnnotations option helps to
overcome the situation where the annotation has been updated but classes
where such annotation is used have not been recompiled (yet). I see the
two class file attributes merely as a runtime optimization while both
kinds of annotations could be kept in a single attribute. The JVM option
just disables this optimization. So I would still keep the option.
Regards, Peter
