You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Motivation:
codegen-java already supports generating
@NonNull
annotations.However, many projects prefer
@Nullable
over@NonNull
annotations.JSpecify also recommends
@Nullable
.Changes:
--nullable-annotation
CLI parameter that defaults tonone
.nullableAnnotation
Gradle/CliJavaCodeGenerator/JavaCodeGenerator property that defaults tonull
.As part of this feature, I propose to also make the following changes:
-non-null-annotation
CLI parameter andnonNullAnnotation
properties accordingly.@NonNull
annotations by default.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:
--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.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
.The text was updated successfully, but these errors were encountered: