4 ms·
The operators are converted to methods, however methods are 'looked-up' at run-time. Not in a hash-table though, think C++ style vtables. So int + float isn't c
by ralfn 10y ago
The operators are converted to methods, however methods are 'looked-up' at run-time. Not in a hash-table though, think C++ style vtables. So int + float isn't compiled to int.addFloat( float ) but to int.add( float ) and then uses polymorphism at run-time.
If you do try to eliminate all of this work at run-time, by creating type-specialized versions of every method, you have the problem that code that tries to narrow a type by either casting, or doing an instance-of check on a supertype (like Object) needs special treatment.
All these choices were made long before they implemented 'generics', so most code was doing manual narrowing and casting all over the place, including the standard API's. Type-erasure would not actually improve the performance by much since it could hardly be used.
They solved the performance problem, without actually considering the type system. Your code runs just as fast, as if you used the Object type everywhere, and just cast on the fly to what you expect it to be. Which would be equivalent to a dynamically typed language.