4 ms·
Interesting. Then, why isn't the bytecode always stored with the caller, that way you can have return-type dispatch?
by jxi 10y ago
Interesting. Then, why isn't the bytecode always stored with the caller, that way you can have return-type dispatch?
- deleted 10y ago[deleted]
- aardvark179 10y agoThe bytecode for method invocation does store the type of the method (which includes the return type), and it is quite valid for a class file to contain multiple methods that are only distinguishable by their return type. You can't normally do this visibly in Java, but I think it's used for bridge methods and a few other things by the compiler.
- josefx 10y agoThe Java bytecode stores it, however the Java language normally does not expose it. Having the compiler select the correct overload based on return type would most likely add a lot of complexity to the language itself ( have you seen the current overload resolution rules? ) without much benefit. I think the compiler actually has to work around that when you narrow the return type of an overriden function: A method Object Base::get() overriden with Integer Child::get() will result in an additional compiler generated Object Child::get() in the bytecode.
- jdmichal 10y agoYep. They're called "bridge" methods. Though, interestingly, there's only one point that they're mentioned in the language spec, specifically in the case of erasure. Even though they were needed before erasure for exactly this reason. https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#d5e26528 https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm...