Translate nullability/optional typescript properties and methods into @Nullable / @NotNull annotations in the Java CDK

[ivoanjo]

Please add the @Nullable / @NotNull annotations as appropriate when generating the Java CDK bindings from typescript constructs that are marked as optional or as not optional.

Use Case

While Java has no native way of saying "this can be null" / "this is not expected to be null", the @Nullable / @NotNull annotations are a way of doing that, enabling

• Developers working on IDEs such as IntelliJ to get helpful messages when they don't check for null
• Tools such as FindBugs to find problematic usages in a codebase

and even better in my case

• The Kotlin compiler reads those and translates it to Kotlin's nullable or not-nullable types, which are then enforced at compile-time!

Proposed Solution

Add the annotations when generating Java code.

Other

There's also a feature request asking for this in the AWS Java SDK, which unfortunately has not been addressed yet.

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[RomainMuller]

We used to have code annotated with @Nullable, but it was pulled due to the lack of a clear standardization around those annotations.

I was however not aware of the Kotlin behavior you describe.

I would tend to favor the JSR-305 annotations.

[ivoanjo]

We used to have code annotated with @Nullable, but it was pulled due to the lack of a clear standardization around those annotations.

Oh, that's interesting, didn't notice it.

Yeah, for Kotlin it would definitely be very useful -- and the Kotlin compiler supports JSR-305 so that would work great for us.

• IntelliJ also supports JSR-305: https://blog.jetbrains.com/idea/2011/03/more-flexible-and-configurable-nullublenotnull-annotations/
• As does findbugs: http://findbugs.sourceforge.net/findbugs2.html#jsr305

So even though it's not standard for those tools, all of them support JSR-305 so targetting that would be enough to work with all of them :)

[RomainMuller]

In fact, steering away from JSR-305 (it's dormant and causes issues with Java 11 due to it's using the javax.* namespace in violation of the JVM license agreement).

Since the main upsides here is facilitating Kotlin interoperability, I'm rooting for the JetBrains annotations at this point.