Allow protected member access of java.lang.Object#2183
Conversation
fe9b872 to
c883b01
Compare
| if (ClassDumper.classesInSamePackage(targetClass.getClassName(), sourceClassName)) { | ||
| return true; | ||
| } | ||
| if (Object.class.getName().equals(targetClass.getClassName())) { |
There was a problem hiding this comment.
Does it also need ... && member.notPrivate()?
There was a problem hiding this comment.
Also, should we ensure targetClass is sourceClass or a subclass of it?
There was a problem hiding this comment.
Line 508 checks whether this member is protected or not. I don't think a method can have protected and private.
Line 519 checks whether it's subclass or not. Now I think this condition should be in ClassDumper.isClassSubClassOf. Updating this.
There was a problem hiding this comment.
I changed my mind. Line 519 requires to load java.lang.Object. But the current code (c883b01) doesn't require it and it's obvious that all objects are subclass of java.lang.Object. So I keep the code as it is.
For other superclasses, line 519 checks the class hierarchy relationship.
There was a problem hiding this comment.
Line 508 checks whether this member is protected or not.
Ah, I missed it.
Also, should we ensure
targetClassissourceClassor a subclass of it?
Maybe I misunderstood the context, but what I mean above is this:
Object obj = new Object();
Runnable runnable = new Runnable() {
@Override
public void run() {
// sourceClass = runnable
// targetClass = obj
// runnable cannot call obj.clone() as it's protected
obj.clone(); // doesn't compile
}
};Or, is it that I'm out of the context?
There was a problem hiding this comment.
Thank you for the example. That's a new perspective to me. Unfortunately Linkage Checker cannot determine such cases. In this example below, the two references are the same to Linkage Checker:
As Linkage Checker deal with class files in JAR files, we can assume the code related to the java.lang.Object methods are already passed the compilation.
There was a problem hiding this comment.
Created an issue for this potential false negatives.
suztomo
left a comment
There was a problem hiding this comment.
@chanseokoh PTAL.
| if (ClassDumper.classesInSamePackage(targetClass.getClassName(), sourceClassName)) { | ||
| return true; | ||
| } | ||
| if (Object.class.getName().equals(targetClass.getClassName())) { |
There was a problem hiding this comment.
I changed my mind. Line 519 requires to load java.lang.Object. But the current code (c883b01) doesn't require it and it's obvious that all objects are subclass of java.lang.Object. So I keep the code as it is.
For other superclasses, line 519 checks the class hierarchy relationship.
Allow protected member access of java.lang.Object, because all objects are subclasses of java.lang.Object.
Fixes #2177. Before this change Linkage Checker would throw errors on the methods of java.lang.Object:
However, the member is "protected" (https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#finalize()) and java.lang.Object is the super class of all Java classes. These errors are false positives. This PR fixes this problem.