mattrpav commented on PR #1093:
URL: https://github.com/apache/wicket/pull/1093#issuecomment-2631679777
> The whole nullability discussion has been going on for years. There are
findbugs annotations, checker framework annotations, jetbrains, nullaway,
javax/jakarta and many more. All of them have their advantages and
disadvantages. JSpecify is an attempt (by Google, Facebook, Uber, etc) to
standardize these annotations and define their exact **semantics**.
There is also a huge graveyard of dead projects from large organizations
that take passes at solving for short comings.
I agree, that the spec could be improved. I agree the the Jakarta Annotation
Team should take this up-- if a spec doesn't meet the needs of users, it won't
be viable.
> The jakarta.annotation package is simply not enough. There is no way using
only these annotations to define the default nullability of a
module/package/class. What does it mean now when a parameter is **not
annotated**? Does it mean it is nullable? Or is its nullability unspecified?
JSpecify solves these ambiguities.
If something isn't marked, it should be presumed to be 'nullable', since
that is the language default.
IMO, less noise is better. Nulls are a feature, not a bug. Null values don't
use memory or require object allocations that need to be garbage collected.
Annotating everything and throwing Optionals everywhere creates non-zero side
effects and performance impacts.
Related Jakarta Annotation update requested:
ref: https://github.com/jakartaee/common-annotations-api/issues/145
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
