Clarifying record reflective support
daniel.smith at oracle.com
Tue Dec 3 16:49:27 UTC 2019
> On Dec 3, 2019, at 9:35 AM, John Rose <john.r.rose at oracle.com> wrote:
> I have two concerns concerning JVM behavior:
> 1. Keep class file loading fast and simple.
> 2. Perform deeper checks only when reflection is performed.
We just discussed on the phone, this is consistent with the consensus.
> This subtly affects the reflective API points which return information that
> depends on classfile attributes (when, as is often the case, such attributes cannot
> be fully validated at class load time). Such API points as getInnerClasses and
> getRecordComponents must be allowed to throw errors for “partially broken”
> class files.
> (Do we need a specific term for “partially broken” here? We might say
> “reflectively invalid” I suppose.)
> The javadoc is relatively silent about reflectively invalid class files,
> but don’t take that as evidence that failure is impossible.
> Should getRC document failure modes? Maybe, but if they are just the
> same as those affecting getMethods, getInnerClasses, etc., there’s no need
Yes, I've been trying to articulate this point in these discussions, but haven't quite put my finger on it. There are *many* undocumented ways in which reflection can fail on class files that don't conform to the expected format. We could decide to make these failure modes explicit, but that's a big job; in the mean time we should be careful not to apply more scrutiny to the specification of 'isRecord' than we do to every other method in java.lang.Class.
Fine: "isRecord returns true if the class extends java.lang.Record and has a Record attribute." (a little more detailed than most reflection methods, but that's probably good)
Overkill: "isRecord returns true if the class extends java.lang.Record and has a Record attribute that conforms to the following rules ..."
More information about the amber-spec-experts