[
https://issues.apache.org/jira/browse/WICKET-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923380#comment-17923380
]
ASF GitHub Bot commented on WICKET-7145:
----------------------------------------
jstuyts commented on PR #1093:
URL: https://github.com/apache/wicket/pull/1093#issuecomment-2631560770
> Is there a reason you went with `jakarta-annotations` and not with
[JSpecify](https://jspecify.dev)?
>
> JSpecify is intended to be the defacto standard and Spring Framework
[recently
migrated](https://github.com/spring-projects/spring-framework/issues/28797) all
their annotations to it. I recently annotated our main project with it but I
went the other way and used JSpecify's [recommended
strategy](https://jspecify.dev/docs/applying/) of applying `@NullMarked` on the
package level und marking `@Nullable` parameters.
I have been a Kotlin developer for years, so I have no knowledge of recent
annotation libraries. I chose the Jakarta annotations because the library was
already in the BOM. But the annotations for nullability had not been used
anywhere yet.
As for the other concerns:
* Something that is not annotated will indeed have an ambiguous meaning: it
is nullable, or it has not been checked for non-nullability yet. Specifying at
some higher level that all of the API is nullable if marked (or the other way
around) won't help here: you still need to add an annotation to each variable
or method that is nullable (or not) before it matches how the code behaves.
Until that has been done, the other variables and methods are ambiguous too.
* About using `@Nonnull`: in Java the default is that a reference is
nullable, so for me it is more logical to state that you cannot assume the
standard Java semantics.
> Developer experience improvement: nullability
> ---------------------------------------------
>
> Key: WICKET-7145
> URL: https://issues.apache.org/jira/browse/WICKET-7145
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 10.4.0
> Reporter: Johan Stuyts
> Priority: Minor
> Attachments: WICKET-7145.patch
>
>
> Knowing whether a variable can be {{null}} or not, improves the developer
> experience. A first step is to add {{@Nonnull}} to parameters that are
> checked for {{{}null{}}}.
> The patch adds {{@Nonull }}to those parameters. The following has been done:
> * The annotation has been added to base and sub types, and to some overloads.
> * Conditional nullability has been taken into account.
> ** In some methods in {{Files}} the client may pass values for other
> parameters that allows the non-{{{}null{}}} parameter to be {{{}null{}}}. It
> is assumed that clients do not do this. If a client checks if the
> non-{{{}null{}}} parameter may be {{{}null{}}}, the client can better skip
> the call.
> In some hierarchies the handling of {{null}} is inconsistent. The contract of
> the base method has to be tightened, or the implementations need to be
> changed to support {{{}null{}}}:
> * {{{}org.apache.wicket.request.Response.encodeURL{}}}: the annotations has
> only be added to the implementations in {{ServletWebResponse}} and
> {{{}WebSocketResponse{}}}.
> * {{{}org.apache.wicket.request.http.WebResponse.encodeRedirectURL{}}}: the
> same holds true as above.
> *
> {{{}org.apache.wicket.request.mapper.parameter.IPageParametersEncoder.encodePageParameters{}}}:
> the annotation has only be added to the implementation in
> {{{}UrlPathPageParametersEncoder{}}}.
> In addition bugs were found and fixed:
> * The order of the parameters to {{Checks.notNull(...)}} in
> {{{}OriginResourceIsolationPolicy{}}}.
> * The order of parameters to {{assertNull(...)}} in {{BaseWicketTester}} and
> {{{}WicketTesterTest{}}}.
> The patch is quite big, but the changes are small and simple. The changes can
> be viewed here:
> https://github.com/apache/wicket/compare/master...jstuyts:wicket:add-non-null-to-parameters
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
