IdentityObject & abstract superclasses

[Peter Levart]

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 ...

Regards, Peter