Upgrade to Kotlin 1.1.51

build.gradle

@@ -18,7 +18,7 @@ import org.gradle.api.internal.plugins.osgi.OsgiHelper
  */
 
 buildscript {
-  ext.kotlinVersion = '1.1.4-3'
+  ext.kotlinVersion = '1.1.51'
   repositories {
 	maven { url "http://repo.spring.io/plugins-release" }
   }
@@ -155,12 +155,12 @@ configure(subprojects) { p ->
 
   compileKotlin {
 	kotlinOptions.jvmTarget = "1.8"
-	kotlinOptions.freeCompilerArgs = ["-Xjsr305-annotations=enable"]
+	kotlinOptions.freeCompilerArgs = ["-Xjsr305=strict"]
   }
 
   compileTestKotlin {
 	kotlinOptions.jvmTarget = "1.8"
-	kotlinOptions.freeCompilerArgs = ["-Xjsr305-annotations=enable"]
+	kotlinOptions.freeCompilerArgs = ["-Xjsr305=strict"]
   }
 
   if (JavaVersion.current().isJava8Compatible()) {

src/docs/asciidoc/kotlin.adoc

@@ -64,30 +64,33 @@ all the Kotlin extensions available.
 == Null-safety
 
 One of Kotlin's key features is https://kotlinlang.org/docs/reference/null-safety.html[null-safety]
-which cleanly deals with `null` values at compile time rather than bumping into the famous
+- which cleanly deals with `null` values at compile time rather than bumping into the famous
 `NullPointerException` at runtime. This makes applications safer through nullability
 declarations and expressing "value or no value" semantics without paying the cost of wrappers like `Optional`.
 (Kotlin allows using functional constructs with nullable values; check out this
 http://www.baeldung.com/kotlin-null-safety[comprehensive guide to Kotlin null-safety].)
 
 Although Java does not allow one to express null-safety in its type-system, Reactor <<null-safety,now
-provides null-safety>> of the whole Reactor API via tooling-friendly annotations declared in
-the `reactor.util.annotation` package.
+provides null-safety>> of the whole Reactor API via tooling-friendly annotations declared
+in the `reactor.util.annotation` package.
 By default, types from Java APIs used in Kotlin are recognized as
 https://kotlinlang.org/docs/reference/java-interop.html#null-safety-and-platform-types[platform types]
 for which null-checks are relaxed.
 https://github.com/Kotlin/KEEP/blob/jsr-305/proposals/jsr-305-custom-nullability-qualifiers.md[Kotlin support for JSR 305 annotations]
-available as of https://blog.jetbrains.com/kotlin/2017/08/kotlin-1-1-4-is-out/[1.1.4 release]
 + Reactor nullability annotations provide null-safety for the whole Reactor API to Kotlin developers,
 with the advantage of dealing with `null` related issues at compile time.
 
-For now, one needs to use a `-Xjsr305-annotations=enable` flag (specified via the
-`freeCompilerArgs` property with Maven or Gradle Kotlin plugins), but that should become
-the default behavior in an upcoming release of Kotlin.
+The JSR 305 checks can be configured by adding the `-Xjsr305` compiler flag with the following
+options: `-Xjsr305={strict|warn|ignore}`.
+
+For kotlin versions 1.1.50+, the default behavior is the same to `-Xjsr305=warn`.
+The `strict` value is required to have Reactor API full null-safety taken in account
+but should be considered experimental since Reactor API nullability declaration could evolve
+even between minor releases and more checks may be added in the future).
 
 [NOTE]
 ====
 Generic type arguments, varargs and array elements nullability are not supported yet,
-see https://github.com/reactor/reactor-core/issues/878[issue #878] for up-to-date informations.
+but should be in an upcoming release, see https://github.com/Kotlin/KEEP/issues/79[this dicussion]
+for up-to-date information.
 ====
-