Skip to content

Conversation

@jbl428
Copy link
Contributor

@jbl428 jbl428 commented Nov 11, 2025

Summary

resolves #1251

Added CheckerFramework to enable compile-time null-safety checking and improve null safety validation.
Added @Nullable annotations across the codebase to explicitly express nullability and strengthen null-safety.

(Optional): Description

  • Added SuppressWarnings to skip null checks for existing code that wasn't handling null validation properly.

  • Added @Nullable annotations where it seemed safe to do so - please review to make sure this won't cause any issues.

  • Disabled nullability checks for test files.

  • Changed some Kotlin types from nullable to non-null - please double-check that these changes are safe.

  • After applying checkFramework, the compiler now shows warnings when @Nullable annotations aren't placed directly next to the type:
    I actually addressed this in a previous PR, but it seems the commit got lost during conflict resolution. I'll handle this in a separate PR.

@Nullable
private Boolean optionValidOnly; // invalid

private @Nullable Boolean optionValidOnly; // valid

How Has This Been Tested?

Run tests

Is the Document updated?

No

}

@Property
fun keyNullThrows() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be removed? It would be better if it remained.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the following code, mapKey is recognized as not null, which causes a compilation error in Kotlin, so I removed the null check.

private void setMapKey(Object mapKey) {
    if (mapKey == null) {
       throw new IllegalArgumentException(
          "Map key cannot be null."
       );
    }

    setValue(
       this.declarativeExpression.element(entrySize - 1).key(),
       mapKey
    );
}

Would it be better to declare mapKey as nullable to handle this issue?

I have one question: since passing null to the key would result in an error, I thought it would be better to prevent null from being passed at compile time. Is there a specific reason why null is allowed in this case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbl428

Would it be better to declare mapKey as nullable to handle this issue?

Yes, that would be nice.

Is there a specific reason why null is allowed in this case?

As the InnerSpec is the public API, users can enter any value, including null. Therefore, all parameters in the InnerSpec should be marked as @Nullable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

535b3f0

Done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add compile-time null safety with @NullMarked and NullAway

2 participants