theigl commented on PR #1093: URL: https://github.com/apache/wicket/pull/1093#issuecomment-2631517598
> > 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. > > If JSpecify's approach becomes the standard, it will be in an updated release of the jakarta.annotation API. I do not see any reason to bring in a non-standard dependency when the standardized Jakarta-based solution is sufficient. 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**. 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. Having said that, annotating with jakarta.annotation is probably still better than nothing, though I would have preferred annotating with `@Nullable` instead. -- 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]
