4 ms·
That's a common misconception about the JVM. Although the language features allow type-erasure, the JVM actually stores the types with the data and uses tracing
by ralfn 10y ago
That's a common misconception about the JVM. Although the language features allow type-erasure, the JVM actually stores the types with the data and uses tracing for optimization. This keeps the compiler output smaller and allows classes to be compiled independently.
- ungzd 10y agoStill it doesn't have to check overloaded arithmetic operators each time and to look up class instance properties in hash table.
- ralfn 10y agoThe 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.