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. -- 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]
