Enable strict null-safety for Kotlin projects

[mkheck]

In order to leverage our prior & continuing efforts to incorporate jsr305-style annotations throughout Spring Framework 5 & various Spring projects (e.g. Spring Boot 2) to indicate the nullability/non-nullability of APIs for full Kotlin interoperability/support, we should provide freeCompilerArgs directives, as indicated below, in build files created by the Initializr:

sourceCompatibility = 1.8
compileKotlin {
    kotlinOptions {
        jvmTarget = "1.8"
        freeCompilerArgs = ["-Xjsr305=strict"]
    }
}
compileTestKotlin {
    kotlinOptions {
        jvmTarget = "1.8"
        freeCompilerArgs = ["-Xjsr305=strict"]
    }
}

Currently, the freeCompilerArgs directives aren't being produced/placed in build.gradle files produced for Spring Boot 2.0 Kotlin applications, which by default results in no nullability information for Spring libraries being available to the Kotlin compiler.

If you need any other information, happy to provide it. Thanks very much!

[mkheck]

We should also include the corresponding directives in the generated pom.xml file for Maven users, of course.

Per the following referenced discussions, here are the appropriate Maven pom additions:

<args>
    <arg>-Xjsr305=strict</arg>
</args>

References:
https://youtrack.jetbrains.com/issue/KT-21592
https://kotlinlang.org/docs/reference/using-maven.html

I'll submit a PR with the noted additions for review.

[snicoll]

I have no opinion on the feature as I am not using it myself (but I've pinged @sdeleuze for feedback).

On a more pragmatic front, the release notes announcing this feature states:

Note that the strict mode JSR-305 support in the compiler is an experimental feature.

I am not keen to enable an experimental feature by default. We've had that discussion before and I think that's for the best. Let's wait to hear from @sdeleuze

[sdeleuze]

While it is indeed defined as experimental, null-safety has been refined and documented in 1.1.60, has seen no change/regression in Kotlin 1.2, but more importantly all the feedbacks I got during conferences shows that this is considered as the number 1 feature of Spring Kotlin support. Notice that Spring Framework leverages JSR 305 annotations, but also Spring Data and Reactor. Without this option enabled, you can have NPE when using Spring Data, defeating Kotlin null-safety key feature.

Given my experience on various Kotlin projects, I would vote for enabling this feature most likely wanted by almost all Spring + Kotlin developers and leveraging this Spring Kotlin support key feature.

[wilkinsona]

FWIW, I'm in favour of enabling this. If that turns out to be a mistake we can always revert.

[mkheck]

I would like very much to update the tests as you specify and submit a PR to close this out, if it’s decided to do so. Please let me know if you would allow me to do that, happy to help out. :)

…

On Feb 7, 2018, at 14:39, Andy Wilkinson ***@***.***> wrote: FWIW, I'm in favour of enabling this. If that turns out to be a mistake we can always revert. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mkheck]

OK, so I guess you just did it yourself. Thanks.

[snicoll]

I had started to investigate if we shouldn't externalize the generation of such options rather than hard-coding them and realized half-way that it's fine as is right now. The job was done at that point so I wasn't going to revert it.