Skip to content

Conversation

@kevinherron
Copy link
Collaborator

What problem(s) was I solving?

The codebase lacked null-safety annotations, making it harder for consumers and tooling to reason about nullability contracts in the API. Without explicit nullability documentation, users must guess whether methods can accept or return null values.

What user-facing changes did I ship?

  • All packages in the library are now annotated with @NullMarked from JSpecify, indicating that by default, all type usages are non-null unless explicitly annotated otherwise
  • JSpecify 1.0.0 is now a compile-time dependency (it has no runtime footprint)

This is a non-breaking change that adds metadata only. Existing code continues to work unchanged.

How I implemented it

  1. Added JSpecify 1.0.0 to the parent POM's <dependencyManagement> section with a version property
  2. Added JSpecify as a dependency to each submodule (byteops, byteops-netty, byteops-unsigned)
  3. Created package-info.java files in each module's com.digitalpetri.util package with the @NullMarked annotation

How to verify it

Manual Testing

  • mvn clean package passes
  • Verify package-info.java files are included in generated JARs:
    jar tf byteops/target/byteops-*.jar | grep package-info
    

Description for the changelog

Add JSpecify 1.0.0 dependency and @NullMarked annotations to enable null-safety documentation for all packages.

Add JSpecify 1.0.0 as a dependency to enable null-safety annotations.
Create package-info.java files with @NullMarked for each module's
com.digitalpetri.util package.
@kevinherron kevinherron merged commit 276b9e3 into master Dec 30, 2025
1 check passed
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.

2 participants