Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

codegen-java: Support generating @Nullable annotations #811

Open
translatenix opened this issue Nov 14, 2024 · 0 comments
Open

codegen-java: Support generating @Nullable annotations #811

translatenix opened this issue Nov 14, 2024 · 0 comments

Comments

@translatenix
Copy link
Contributor

translatenix commented Nov 14, 2024

Motivation:
codegen-java already supports generating @NonNull annotations.
However, many projects prefer @Nullable over @NonNull annotations.
JSpecify also recommends @Nullable.

Changes:

  • Add a --nullable-annotation CLI parameter that defaults to none.
  • Add a nullableAnnotation Gradle/CliJavaCodeGenerator/JavaCodeGenerator property that defaults to null.
  • Annotate nullable types with the configured annotation (if any).

As part of this feature, I propose to also make the following changes:

  • Change the -non-null-annotation CLI parameter and nonNullAnnotation properties accordingly.
  • Do not generate @NonNull annotations by default.
  • Deprecate org.pkl.java.config.mapper.NonNull and encourage users to switch to JSpecify.
    Note that tools won't recognize org.pkl.java.config.mapper.NonNull unless explicitly configured.

Open question:
@Nullable must be accompanied by @NullMarked (JSpecify) or @NonnullByDefault (JSR 305).
I can think of two ways to go about this:

  1. Introduce --null-marked-annotation and annotate config classes accordingly.
    This is the most consistent solution, but it requires yet another CLI parameter and property.
    It can be made more convenient by inferring the correct annotation based on --nullable-annotation and --non-null-annotation for popular libraries such as JSpecify and JSR 305.
  2. Leave it to users to add a package-info.java with a @NullMarked annotation.
    This is a clean and simple solution. However, it is less convenient than (1).
    It could, in theory, cause problems if users compile generated and handwritten code separately and don't have a place where to put package-info.java.

Final thought: The Java ecosystem is converging on JSpecify. For many users, the best option would be --generate-jspecify-annotations.

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

No branches or pull requests

1 participant