You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With JDK 16 there will be stricter limits on what may be accessed via Reflection: many checks that formerly resulted in a warning will start failing. While this does not cause many breakages so far (based on unit tests), it does seem like there are cases where unnecessary access attempts are made on some JDK types.
One way to reduce these cases would to make default visibility (see @JsonAutoDetect) settings bit stricter for JDK types (as defined by class being under "java." or "javax." packages): specifically, to require "public" visibility for accessors including setters.
This should help reduce access attempts that are not really needed but that may lead to failures.
Beyond this it will probably make sense to also prevent calls to "setAccessible()" for members of same types, but first things first.
The text was updated successfully, but these errors were encountered:
With JDK 16 there will be stricter limits on what may be accessed via Reflection: many checks that formerly resulted in a warning will start failing. While this does not cause many breakages so far (based on unit tests), it does seem like there are cases where unnecessary access attempts are made on some JDK types.
One way to reduce these cases would to make default visibility (see
@JsonAutoDetect
) settings bit stricter for JDK types (as defined by class being under "java." or "javax." packages): specifically, to require "public" visibility for accessors including setters.This should help reduce access attempts that are not really needed but that may lead to failures.
Beyond this it will probably make sense to also prevent calls to "setAccessible()" for members of same types, but first things first.
The text was updated successfully, but these errors were encountered: