-
Notifications
You must be signed in to change notification settings - Fork 165
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
Base64
whitelists did not work due to use of canonical rather than binary name
#339
Conversation
This plugin might be a good candidate for JEP-229:
|
// TODO this should be more strict: binary name is required for nested classes | ||
return ClassUtils.getClass(name); |
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.
Maybe we could add an assertion here so that any issues with the static whitelists will cause the plugin's tests to fail?
// TODO this should be more strict: binary name is required for nested classes | |
return ClassUtils.getClass(name); | |
Class<?> clazz = ClassUtils.getClass(name); | |
assert clazz.getName().equals(name); // The whitelists require binary names, but ClassUtils allows various syntaxes. | |
return clazz; |
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.
Well that would basically be the same as
// TODO this should be more strict: binary name is required for nested classes | |
return ClassUtils.getClass(name); | |
return Class.forName(name); |
which will not work (AFAIK) because name
is sometimes something like int
or Object[]
. We want to enforce use of binary name on the actual class name portion of the string, while still processing special syntaxes that ClassUtils
supports. I spent a few minutes thinking about it and did not come up with a simple fix so I moved on.
Mistake in #309/#310.