Allow @NonNull on the parameters of abstract/interface methods

[lombokissues]

Migrated from Google Code (issue 772)

[lombokissues]

👤 r.spilker   🕗 Jan 22, 2015 at 16:55 UTC

Rationale: They serve a documentation purpose and we don't want to force the users to add a different @ NonNull for just those cases.

[lombokissues]

End of migration

[alexandroid]

I found it counter-intuitive that putting @NonNull on a method parameter in an interface does not generate the null-checks for all concrete implementations of that interface (i.e. serving both as documentation and implementation).

Is there a reason or convention which prevented Lombok from doing this?

[signaflo]

I found it counter-intuitive that putting @NonNull on a method parameter in an interface does not generate the null-checks for all concrete implementations of that interface (i.e. serving both as documentation and implementation).

Is there a reason or convention which prevented Lombok from doing this?

@alexandroid, see this discussion here: https://stackoverflow.com/questions/15607060/java-interface-throws-an-exception-but-interface-implementation-does-not-throw-a

The accepted answer is a quote from Stan James:

A general rule of implementing and extending is you can make your new class or interface "less restrictive" but not "more restrictive". If you think of the requirement to handle an exception as a restriction, an implementation that doesn't declare the exception is less restrictive. Anybody who codes to the interface will not have trouble with your class.

I agree that it would be confusing for an interface to declare an exception thrown under a given condition, but an implementation of that interface to not throw it. It's up to the implementer of the interface to abide by the contract defined in the interface or to clearly document the reason for not doing so.