Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Created a new detector for rule MET04-J #1994
base: master
Are you sure you want to change the base?
Created a new detector for rule MET04-J #1994
Changes from all commits
a483929
912d9fe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current implementation there is a hit type, which may cause problems for the users, so we may need filter it out: we have three classes: SuperClass, Class, and SubClass, SuperClass is parent of Class, which is parent of SubClass. We have a method, which is declared in SuperClass as protected, overriden in both Class and SubClass as public. There will be a hit in Class, which is great, but there will be also a hit in SubClass, about which I'm not so sure. If the user have no write access to SuperClass and Class, then can't really do anything about the problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure, if this can occur in real life. Do SpotBugs analyze classes to which the user has no write access? For example in dependencies? I see your point, can you maybe show me an example of it where I can reproduce the hit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the user provided the necessary compiled files for the analysis, even if doesn't have write access to them, cause e.g. they are inside a jar file. Checked every hit of the tests on the bigger projects, but didn't find any test like the one, I mentioned. (Otherwise I would have referred it.) You can create a test by simply creating a class, which descends from one of the hits and overrides the appropriate function, or reusing your already existing test classes, using
SuperClassOfSuperClass
as SuperClass in my example,SuperClass
as Class, andSubClassFromSamePackage
as SubClass. If you simply add an override ofsuperPackagePrivateMethodToPublic()
toSuperClass
, then you have the test:IMO in this case, the error should be only reported in
SuperClass
, and not inSubClassFromSamePackage
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sajtizsolt Can you please create a testcase like this and modify the code to not to bury our users in hits they can't do anything about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will, I'm just a littly busy nowadays. I will tag you if it happens!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JuditKnoll Now I thought about this problem again. To achieve the desired behaviour, we should be able to filter out potential bugs based on the bugs already found while we analyzed the super classes of the current class. I don't know, if there is some logic implemented in SpotBugs which enables us to query this list of bugs based on a class, but if there is not, then we should analyze every single super class again. I don't know, I feel that this would increase the complexity of the detector by a huge scale. Do you feel, that the added value of this solution complies with the amount of extra computational demand of it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, I've added the requested changes in another commit - take a look at them. Not terribly slow if there are few super classes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think having a more precise detector is worth the increased complexity. Usually there is less than 10 super classes, so it's not as much of an overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, IMO there is a solution which only needs to check every super class only once, if we take advantage of the order of visiting, and maintain a collection of the correct methods of the examined class. If we phrase the problem like this, that may help: an IAOM bug should be reported, when there is an increase of accessibility of a method from the closest parent declaring/overriding the given method.
When the bug is reported, there is an accessibility increase, then we can remove the current buggy method from the methods of the examined class (
subClass
) collection. This way, we don't need to check at every parent whether the same bug got reported or not, also, the number of methods to check against decreases.Removing a method won't cause a problem, since a method can only have one IAOM bug in one class, and the closer parent will be visited first, since
JavaClass.getSuperClasses()
contains the list of super classes in ascending order.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Answering your question about filtering out bugs based on other bugs, there is a solution using
BugAccumulator
, but it's a bit different to what you need. As far as I know, that one only works inside one class, not across classes.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does work, but it could be a bit more efficient, see my comment at the
visitClassContext()
method.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can also filter out the static initializer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure, that checking the signatures is enough to check two methods are the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
Method
class itself has an equals, which checks both the name of the method and the signature. Is there any reason, why you don't use that equals?