hengyunabc opened SPR-16684 and commented
wrappedObject is @Nullable
:
@Nullable
Object wrappedObject;
But getWrappedInstance() throw exception:
public final Object getWrappedInstance() {
Assert.state(this.wrappedObject != null, "No wrapped object");
return this.wrappedObject;
}
spring 4 is ok, why spring 5 throw exception?
No further details from SPR-16684
Comment From: spring-projects-issues
Juergen Hoeller commented
You should never arrive at such a nested null
object within a BeanWrapper
... Could you please arrange a unit test that fails on Spring 5 but passes against Spring 4?
Comment From: spring-projects-issues
Juergen Hoeller commented
Are you doing custom calls to getWrappedInstance()
there? In that case you might indeed see a change from Spring 4 in that Spring 5 generally enforces non-null objects in quite a few places, as part of its wider nullability revision. However, within the framework, there should not be a regression since we're consistently calling getWrappedInstance()
with a non-null expectation now.
Comment From: spring-projects-issues
hengyunabc commented
BeanWrapper
/**
* Return the bean instance wrapped by this object, if any.
* @return the bean instance, or {@code null} if none set
*/
Object getWrappedInstance();
/**
* Return the type of the wrapped JavaBean object.
* @return the type of the wrapped bean instance,
* or {@code null} if no wrapped object has been set
*/
Class<?> getWrappedClass();
The implement break the javadoc.
Comment From: spring-projects-issues
Juergen Hoeller commented
That was in 4.3.x where this was still the case... As of 5.0, it doesn't suggest any null
values in the javadoc anymore since we're enforcing non-null access there. This is one of the compromises we had to make in our nullability revision, providing stronger non-null guarantees to callers.
Comment From: spring-projects-issues
hengyunabc commented
Ok, I understand what you mean, thank you very much. Please close this issue.