IdentityObject & abstract superclasses
peter.levart at gmail.com
Thu Sep 3 07:03:24 UTC 2020
On 9/3/20 1:30 AM, Dan Smith wrote:
> (Optionally) The method Class.Interfaces(), and similar reflection API points, filters out IdentityObject when it is not explicitly named in the class file.
While this might sound ok from standpoint of not disturbing existing
code that uses reflection, it is not consistent with other methods in
the reflection API and language itself. For example, if (o instanceof
IdentityObject) evaluates to true, but o.getClass().getInterfaces() does
not contain IdentityObject.class, then this means more trouble than it
is worth. Reflection API has always been more about modeling runtime
representation than explicit source-level language constructs.
Class.getDeclaredConstructors() for example returns implicit default
constructor that has not been explicitly declared,
Constructor.getParameterTypes() includes the type of implicit outer
instance parameter in inner classes, etc...
The difference here is that all existing implicit constructs are
generated by javac and are explicitly present in the class file.
IdentityObject OTOH is to be added by VM in case it does not exist in
class file (only for class files compiled for target < X.0, because for
target >= X.0, javac would already take care of that either by adding
the interface implicitly to class file or forcing user to add it to
source). But from user standpoint it does not matter because user only
sees Java source code on one side and the program behavior on the other
side. (s)he very rarely looks into bytecodes/classfile. (s)he would also
be surprised to find reflection behavior change depending on whether
some source was compiled for target < X.0 vs. target >= X.0 ...
More information about the valhalla-spec-observers