[
https://issues.apache.org/jira/browse/WICKET-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924432#comment-17924432
]
ASF GitHub Bot commented on WICKET-7145:
----------------------------------------
theigl commented on PR #1093:
URL: https://github.com/apache/wicket/pull/1093#issuecomment-2639200126
> 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.
I prefer the JSpecify branch because of the advantages you mentioned!
> 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.
What I did in my project is this:
1. Mark a package as `@NullMarked` in `package-info.java`
2. For each class in the package:
- Mark all parameters as `@Nullable` that IntelliJ reported as null
being passed or that is null-checked inside the method
- Mark all return values as `@Nullable` that IntelliJ reported as
possibly returning null
3. Repeat until almost all packages are marked and IntelliJ shows no more
warnings
4. Optional: Remove all `package-info.java` files and place a single
`@NullMarked` annotation in the `module-info.java`.
This is basically the incremental strategy that JSpecify
[recommends](https://jspecify.dev/docs/applying/).
What approach we take will mostly depend on how much time we want to spend.
> 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)
