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
