Can't differentiate between @A(int.class) and @A(Integer.class)

Given the following Java code:

@MyAnnotation(int.class)
class B {
}

@MyAnnotation(Integer.class)
class C {
}

and the following KSP code

val clsB = resolver.getClassDeclarationByName("com.example.B")
val clsC = resolver.getClassDeclarationByName("com.example.C")

val annB = clsB!!.annotations.first().arguments.first().value
val annC = clsC!!.annotations.first().arguments.first().value

val equal = annB === annC

equal is true, which is surprising given that the underlying code is not and int.class == Integer.class would return false.

[ting-yuan]

can this criteria be reliably used to tell boxed/primitve types apart? Is there a guarantee, that this will always be the case?

Yes, it is documented so KSP needs to follow.

What if one uses java.lang.Integer explicitly in Kotlin?

It’ll be non-null java.lang.Integer. Only types in Java sources are mapped.

What if a method in Kotlin (override fun getInt(): Int) overrides a method from Java superclass (Integer getInt()) with an explicitly non-null return-type?

It’ll be non-null kotlin.Int for the Kotlin overrider and kotlin.Int! for the Java overridee.

[Jeffset]

In KSP, primitive types are NOT_NULL, while boxed types are PLATFORM.

Good point, but can this criteria be reliably used to tell boxed/primitve types apart? Is there a guarantee, that this will always be the case? What if one uses java.lang.Integer explicitly in Kotlin? What if a method in Kotlin (override fun getInt(): Int) overrides a method from Java superclass (Integer getInt()) with an explicitly non-null return-type?