jstuyts commented on PR #1093: URL: https://github.com/apache/wicket/pull/1093#issuecomment-2639774324
> I think we can go ahead with your current JSpecify PR and continue improving the annotations in future work. I'll wait for what the final decision will be: Jakarta or JSpecify. > The only minor concern I still have with this PR is that we are adding `@NonNull`. From my experience (and also what JSpecify recommends and large projects like Spring are doing) `@Nullable` makes more sense in the long run. At some point, we will have to remove all these `@NonNull` annotations. But this should be a trivial change. Like I said before: once everything is annotated, it is easy to decide which of the 2 annotations can stay. > And then there is the question of how we continue with this and what we require in future PRs. Is our goal to completely annotate the whole Wicket codebase? Do we add nullability annotations whenever we touch existing code? Do we require them in PRs? Or is this a one-time effort to slightly improve the developer experience? A recommendation to add the annotations when adding or modifying code is the least that can be done. Maybe split PRs: first a PR that adds the annotations to existing code, and then a PR that contains clearer code for the modifications because of the added annotations. This should make reviews easier. Annotating everything would be best, but there are some tricky situations, that force clients that can never see a `null` to work with nullable variables. Here are a few I found so far: * Theoretically `getComponent()` of a behavior can return `null` (for example, call it before binding the behavior), but I think that practically `getComponent()` is never called when the behavior is unbound. There are a couple of options here, but I want to discuss those when I create an issue for behaviors. * The `IValidatable` passed to `IValidator` will not have a `null` value, unless the validator implements `INullAcceptingValidator`. -- 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]
