-
Notifications
You must be signed in to change notification settings - Fork 578
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
Earlier/LaterSubtypes ordering constraint supports only supertypes from SpotBugs itself #215
Comments
Considering doing a pull request for this at the moment. This raises the question: Do we have a test harness in place to test that SpotBugs’s plugin mechanism works as expected (as opposed to a test harness for individual detectors)? |
This lets the PluginLoader load the supertype with the plugin's class loader, not the class loader that loaded the SpotBugs core.
This lets the PluginLoader load the supertype with the plugin's class loader, not the class loader that loaded the SpotBugs core.
Pull request is ready. Testing has been done manually, however, in a scenario akin to the |
Thanks for merging the pull request. |
The following ordering constraints
will fail at runtime with an
edu.umd.cs.findbugs.PluginException
(Unknown class org.example.MyDetector in constraint selector node). The problem apparently is thatPluginLoader
usesClass.forName(String)
rather than the three-argument version which could use the class loader fromPluginLoader.classLoader
rather than the class loaderPluginLoader
itself has been loaded with.The text was updated successfully, but these errors were encountered: