Development: Migrate nullness annotations to JSpecify

[Strohgelaender]

Checklist

General

• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Motivation and Context

In #6872 I added a test to consistently use the Jakarta-Nullness Annotations in Java. This choice was not made since the annotation provides some kind of Advantage, but just because it was used previously in most places.

JSpecify is an Attempt to unify nullness annotations in Java. See https://jspecify.dev/docs/start-here/ for more details. The project sounds promising, let's hope it does not end like this:

Description

This PR is mostly search-and-replace of imports. The only change is done in context of Arrays. @Nullable Object[] means that the array can contain null values, where Object @Nullable [] means that the Array itself can be null. I adopted the places where this is relevant.

Steps for Testing

skim over the code.

Code Review

• Code Review 1
• Code Review 2

[SimonEntholzer]

What's the benefit of using the jspecify Nullable instead of the jakarta Nullable?

[Strohgelaender]

What's the benefit of using the jspecify Nullable instead of the jakarta Nullable?

First there is no downside, the JSpecify annotations are already supported by all relevant tools. In my short experience just while creating this PR there seems to be even better support since IntelliJ reported to cases of primitive types annotated with such annotations which does not make sense, and this warning was not shown with the old ones.

JSpecify additionally contains the Annotation @NullMarked to infer null-safety (You can annotate a class with that which then means that only @Nullable fields are nullable and the rest is non-null by default). We could adapt classes to this behaviour in the future.

JSpecify also contains generics support for these annotations which is not the case for the other ones (obviously this is currently unused in Artemis since this is just a migration but could be useful in the future).

And lastly I think the project's aim is great and should get support, which is only possible if pojects use these annotations.

[az108]

Code changes are consistent and tried basic functionalities of artemis on TS1, nothing seems to be broken trough the nullcheck changes (would also be weird but just wanted to be sure)

[pzdr7]

Looks like some tests are failing as a result of these changes. Can you have a look?

[pzdr7]

This seems to no longer reject null as title / shortTitle values, causing a 500 instead of a 400 in the tests.

MockHttpServletResponse:
           Status = 500
    Error message = null
          Headers = [Vary:"Origin", "Access-Control-Request-Method", "Access-Control-Request-Headers", Content-Version:"1.3.3-beta7", Content-Type:"application/problem+json", X-Content-Type-Options:"nosniff", X-XSS-Protection:"0", Cache-Control:"no-cache, no-store, max-age=0, must-revalidate", Pragma:"no-cache", Expires:"0", Content-Security-Policy:"script-src 'self' 'unsafe-inline' 'unsafe-eval'", Referrer-Policy:"strict-origin-when-cross-origin", Permissions-Policy:"camera=(), fullscreen=(*), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), midi=(), payment=(), sync-xhr=()"]
     Content type = application/problem+json
             Body = {
  "type" : "https://www.jhipster.tech/problem/problem-with-message",
  "title" : "Internal Server Error",
  "status" : 500,
  "detail" : "could not execute statement [NULL not allowed for column \"TITLE\"; SQL statement:\ninsert into knowledge_area (description,parent_id,short_title,title,id) values (?,?,?,?,default) [23502-224]] [insert into knowledge_area (description,parent_id,short_title,title,id) values (?,?,?,?,default)]; SQL [insert into knowledge_area (description,parent_id,short_title,title,id) values (?,?,?,?,default)]; constraint [null]",
  "path" : "/api/admin/standardized-competencies/knowledge-areas",
  "message" : "error.http.500"
}

[Hialus]

I guess JSpecify is not directly supported by the checker that is run before endpoints are called. If there is no way to fix this, this would be a huge downside to using them IMO, as these automatic checks are rather beneficial.

[pzdr7]

Same here, title and knowledgeAreaId being annotated with NonNull seems to cause problems in the tests (the corresponding tests pass once I revert the annotations here and in KnowledgeAreaRequestDTO)

[Strohgelaender]

We need to wait for Spring-support, see spring-projects/spring-framework#28797.

Closing this, I'll re-open this once Spring support is ready.