feature/java api level

[baywet]

related and generation result microsoftgraph/msgraph-sdk-java#558

• updates java generation so it includes nullable and nonnull annotations for kotlin
• adds additional nonnull nullable annotations for java sdk
• updates test files

[zengin]

How do we decide on where to use Nonnull and Nullable?

[baywet]

Flip of a coin?
No, I only tag return types as Nonnull if the body explicitly cannot be null (return this, return new something...).
I only tag parameters as Nonnull if the method cannot work without that parameter, of if there is an overload without this parameter.
I only tag getters as Nonnull if they are initialized (ctor, initialized field...) no matter what, and if the setter is tagged as Nonnull.
I only tag setters as Nonnull if it makes sense semantically.
Rest is tagged as Nullable.

I do get this is a rule of thumb and it won't be perfect. But it's always going to be better for the Kotlin devs out there using the SDK than the compiler taking guesses and defaulting everything as Nullable. Now they'll get warnings as far as I understand if they try to pass a nullable in a nonnull (whether it's something they pass from to our SDK, or something they get from the SDK and use in their code/another lib). And we can always adjust that in the future if we get some feedback.

[zengin]

Flip of a coin?
No, I only tag return types as Nonnull if the body explicitly cannot be null (return this, return new something...).
I only tag parameters as Nonnull if the method cannot work without that parameter, of if there is an overload without this parameter.
I only tag getters as Nonnull if they are initialized (ctor, initialized field...) no matter what, and if the setter is tagged as Nonnull.
I only tag setters as Nonnull if it makes sense semantically.
Rest is tagged as Nullable.

I do get this is a rule of thumb and it won't be perfect. But it's always going to be better for the Kotlin devs out there using the SDK than the compiler taking guesses and defaulting everything as Nullable. Now they'll get warnings as far as I understand if they try to pass a nullable in a nonnull (whether it's something they pass from to our SDK, or something they get from the SDK and use in their code/another lib). And we can always adjust that in the future if we get some feedback.

Thanks for the explanation.