[
https://issues.apache.org/jira/browse/WICKET-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923709#comment-17923709
]
ASF GitHub Bot commented on WICKET-7145:
----------------------------------------
jstuyts commented on PR #1093:
URL: https://github.com/apache/wicket/pull/1093#issuecomment-2634017788
> JSpecify is perfectly usable already but it has a couple of non-intuitive
annotation usages. Your example is one of them. See
https://jspecify.dev/docs/user-guide/#some-subtler-details.
Got it. I have created a branch using JSpecify:
https://github.com/jstuyts/wicket/tree/add-non-null-to-parameters-jspecify
The advantages are:
* It seems like the Java ecosystem is moving to JSpecify as the semantics
are more precise and there is more tooling support.
* The Kotlin compiler understands the annotations of JSpecify.
Let me know if you decide you would like to use JSpecify instead of the
Jakarta annotations. I will close this PR and create a new one.
Another remark about which annotations to use. I think the annotations
should be added incrementally, and both annotations (nullable and not nullable)
must be added. Once everything is annotated (which can take quite some time),
the decision to switch to package-level (or some other level) annotations can
be made. It is then also easy to determine which of the 2 annotations results
in the least amount of code. The most occurring annotation can be changed to
higher-level annotations.
> 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)
