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:
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.
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.
Motivation: codegen-java already supports generating
@NonNullannotations. However, many projects prefer@Nullableover@NonNullannotations. JSpecify also recommends@Nullable.Changes:
--nullable-annotationCLI parameter that defaults tonone.nullableAnnotationGradle/CliJavaCodeGenerator/JavaCodeGenerator property that defaults tonull.As part of this feature, I propose to also make the following changes:
-non-null-annotationCLI parameter andnonNullAnnotationproperties accordingly.@NonNullannotations by default.org.pkl.java.config.mapper.NonNulland encourage users to switch to JSpecify. Note that tools won't recognizeorg.pkl.java.config.mapper.NonNullunless explicitly configured.Open question:
@Nullablemust be accompanied by@NullMarked(JSpecify) or@NonnullByDefault(JSR 305). I can think of two ways to go about this:--null-marked-annotationand 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-annotationand--non-null-annotationfor popular libraries such as JSpecify and JSR 305.package-info.javawith a@NullMarkedannotation. 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 putpackage-info.java.Final thought: The Java ecosystem is converging on JSpecify. For many users, the best option would be
--generate-jspecify-annotations.