The contract didn't break, that's the point

# language-proposals

[jw]

The contract didn't break, that's the point

[Ruckus]

Can you elaborate? I may just be misunderstanding, but changing the signature of a function to include a generic parameter seems like a break of contract to me.

[jw]

It's a bound generic which means it erases to the same signature as before in bytecode. When unspecified in Java, the generic becomes the lower bound making all previous invocations behavior correctly at the source level.

[Ruckus]

I am aware of the erasure behavior. I was thinking from a code level though. While View findViewById(int) and <T : View> T findViewById(int) erase to the same thing, they have different signatures and thus different contracts. The fact that changing from the first to the second works in Java is basically just a quirk of the language. Since you can't go from the second to the first even in Java, wouldn't that be a contract change?

[jw]

It's not a quirk of the language it's an explicit design to allow migration. If they went backwards it would be a source-incompatible but binary-compatible change. Forwards is both source and binary compatible so, thus, not a contract change.

[Ruckus]

Ah, okay. So the findViewById signature didn't change so much as migrate to newer Java style. I guess that makes sense. Thanks for explaining.