This: ``` constructor( title: String, port...
# announcements
f
This:
Copy code
constructor(
    title: String,
    portions: Int,
    sections: List<ClassA>,
    sourceUrl: String? = null
  )
and this:
Copy code
constructor(
    title: String,
    portions: Int,
    ingredients: List<ClassB>,
    sourceUrl: String? = null
  )
Apperently have the same JVM signature, why is that? Can’t it see that
ClassA
and
ClassB
are two different classes in the list? I did not know that two lists with different content looked the same to the bytecode
a
f
I see, smarter people than me probably had a good reason hehe 🙂
“Type erasure ensures that no new classes are created for parameterized types; consequently, generics incur no runtime overhead.” I see 🙂
g
Actually the main reason is backward compatibility of Java with generics with previous versions without Generics (before Java 5)
f
Aww, I was hoping it would be a good reason 😞
g
This approach is not always bad actually, there are some advantages, zero cost of generics is one of them
f
Yeah of course, its there for a reason. It just sucks when things in the future have to be worse than they could be because of backwards compatibility. But thats just reality 🙂 Sometimes I wish the jvm infrastructure would just drop everything pre java6 and get rid of a lot of junk
g
it’s good theoretically, bad in practice. Drop to Java 6 will not help, generics are erased even on Java 10, you need completely new, non backward compatiblechange
f
Yeah its not worth it just because of nicer signature of course 🙂
d
For functions (not constructors) you can use
@JvmName
in Kotlin to work around this. Then you could use a "fake constructor", i.e.
operator fun invoke
in
companion object
and voila 🙂
Example:
Copy code
class Foo {
    companion object {
        operator fun invoke(a: List<String>): Foo = TODO()
        @JvmName("createFromIntList")
        operator fun invoke(b: List<Int>): Foo = TODO()
    }
}