Are Kotlin's reified types incorrect for primitives on the JVM?

问题

If a Kotlin function invocation reifies a primitive, say Int, the 'passed' class is that for the boxed primitive, not the unboxed version.

inline fun <reified T> reify() = T::class

@Test fun reified_type_doesnt_match_for_primitive() {
    assertNotEquals(Int::class, reify<Int>())
    assertNotEquals(Int::class.java, reify<Int>().java)
    assertNotEquals<Any>(Int::class, reify<Int?>())

    val nullableInt: Int? = 42
    assertNotEquals(nullableInt!!.javaClass.kotlin, reify<Int>())

    assertEquals<Any>(java.lang.Integer::class.java, reify<Int>().java)
}

@Test fun reified_type_matches_for_class() {
    assertEquals(String::class, reify<String>())
}

Is this a bug?

回答1:

This is somewhat confusing, but the current behavior is by design. This approach has a major benefit compared to the one where we would treat T::class.java as a primitive class. If the function has a parameter of type T, its Java class is always equal to T::class.java at runtime (assuming T is final). This is actually a very sensible thing to expect:

    inline fun <reified T : Any> foo(t: T) {
        assert(T::class.java == t.javaClass)
    }

This happens because the parameter of a generic type T can only have a reference value at runtime, which is necessarily a boxed value if T is a primitive type.

Also see a thread on the Kotlin forum on this subject: https://devnet.jetbrains.com/thread/475540

来源：https://stackoverflow.com/questions/33987746/are-kotlins-reified-types-incorrect-for-primitives-on-the-jvm