Kotlin中RxJava Flowable的!运算符含义及两类Flowable差异咨询

Hey there! Let's break down your two questions about RxJava's Flowable in Kotlin clearly:

First off, that ! isn't an operator specific to RxJava's Flowable—it's a Kotlin platform type marker. Here's the context:

RxJava is written in Java, which lacks Kotlin's strict null-safety rules. When Kotlin interacts with Java code (like RxJava APIs), the compiler can't be certain if a Java type is nullable or not. To handle this ambiguity, Kotlin uses the ! symbol to mark "platform types"—types whose nullability isn't enforced by the compiler, and it's entirely up to you to handle null checks safely.

So if you see something like Flowable! or Flowable<T!>, it means either the Flowable instance itself (in the case of Flowable!) or the items it emits (like T!) come from Java code, and Kotlin can't guarantee their non-nullability. You'll need to manually check for nulls here to avoid NullPointerExceptions, since the compiler won't flag potential null issues for these types.

Let's break down each type layer by layer to spot the differences:

Flowable<List<VanDataModel>> #

This is a strict Kotlin non-null type with three layers of compiler-enforced safety:

• The Flowable instance itself is non-null—you can't assign null to a variable of this type.
• The List emitted by the Flowable is non-null—every emission will be a valid List (never null).
• Each VanDataModel inside the List is non-null—you don't have to worry about null elements in the list; the compiler will block any code that tries to add a null here.

Flowable<List<VanDataModel!>!> #

This is a combination of platform types, meaning none of the layers have null-safety guarantees from the compiler:

• The outermost ! (after List<VanDataModel!>) means the List emitted by the Flowable is a platform type—it could be null, and the compiler won't warn you if you access it without a null check.
• The VanDataModel! means each element in the List is a platform type—individual VanDataModel instances could be null, again with no compiler warnings to alert you.
• Additionally, since this type typically comes from Java code, the Flowable instance itself might be nullable in practice—you'd need to verify that on your own.

In short:

• The first type gives you full null-safety enforced by the Kotlin compiler.
• The second type leaves all null-checking up to you, which is riskier but necessary when working with unannotated Java RxJava code.

内容的提问来源于stack exchange，提问作者Sujin Shrestha