Look at gson and Jackson for examples. They use a Type reference type class to capture generics available to the class from its ancestor.

They do not do more than kotlin does.

A Java class receiving a parameter of type Class has no more ability than kotlin does.

A Java class receiving Type or TypeReference type class has same as Kotlin.

You are misunderstanding the subject matter, and that's holding you back from seeing how you can do the same in Kotlin with the examples I've already given.

A Java Class reference has erased generics. It does. You cannot change that in Java, or Kotlin. Because you aren't supposed to. It is by design of Java vm generics.

All Methods taking a class receive erased class. All. Everyone.

If yiu think otherwise give me an example and I'll show you that it is erased.

Any example, 100% guarantee.

Other than in Kotlin where some people used reified generics to capture type info by the compiler for a one level call to inline function. But using Class to do that is dangerous.

So I gave you alternatives. It's not a design of Kotlin problem, it's just fact of Java vm. And Kotlin gives you more not less.

You are missing something, and maybe you can give me an example if you still think otherwise.

no offense @apatrida since you have way more experience than I do with this, but I’m feeling that you misunderstand the question I was bringing up. I was only discussing of compiler compile-time (obviously…) checking. As for execution-time availability of types, you’re perfectly right, but that’s a different topic I fear. The use case I was referring to is exactly the one here: https://youtrack.jetbrains.com/issue/KT-9193. The discussion is exactly the same as here simple smile

ah, that.

you want to be able to put a type in a place where it doesn't matter, for benefit of reading or some other checking

(the compiler has nothing to check the type against other than it is valid generics against upper bounds, so really is only for readability)

so let's close this one off and say it doesn't, and likely won't exist and doesn't do anything anyway. and only talk about runtime reflection here.

can we agree not to bring up KT-9193 over and over again? 😄 please?!?! its confusing to drop it into other conversations.

you’re right it’s got nothing to do with reflection actually, we could have stayed in #C0922A726. this issue comes back over and over again because it’s confusing given that it a widely used pattern in Java I guess (that’s what I was trying to say). maybe the docs could include a small section about this use case, I think that’d be valuable 💡

I don't see it in Java either

is not

yeah, you can't do

List<String>.class

in Java

but Java has a slight advantage here because

List.class

means the class of raw List, whereas in Kotlin

List::class

is the class of List of something (

List<*>

)

and raw list can be assigned to any list, as opposed to the list of something

for example,

List<String> l = List.class.newInstance()

would compile in Java

but

val l: List<String> = List::class.newInstance()

won't in Kotlin, because

List::class

is

List<*>

and it can only give back

Any

man, I can barely do anything in Java anymore, the above example was HARD!

anyway, let's shoot KT-9193 into someplace else and go back to "Fun With Reflection (in 21 days)"