Patches for faster interface dispatch, type checking

Fri Dec 10 17:25:00 GMT 1999

Godmar Back wrote:
> It's detected there, but you can't throw the exception at this point.
> You have to delay it until run-time. After all, the call may never happen.
> The JLS is pretty clear on that.

I don't think we care. We clearly and deliberately violate the "binary
compatibility" rules in many ways, at least for code that is compiled
to native code. For example, if class B references any field in A,
B is compiled, then A is changed by adding or removing a field in A,
the the compiled code in B is likely to fail in undiagnosed nasty ways,
since the compiled code of B has hard-wired in offsets for A's fields.
Following the "binary compatibility" rules would result in an unacceptable
overhead, and negate much of the point of pre-compilation. (Ideally we
would have smarter linkers that would detect the mismatch at link time.)
We might be able to follow the "binary compatibility" rules for interpreted
code (or JIT'd code). However, this is not a priority, and we should not
give up any performance for this goal, at least not if it hurts pre-compiled
code. While Gcj does support dynamically-loaded code, the philosophy of
Gcj is to emphasize and optimize for pre-compiled code.
The "binary compatibility" chapter of the JLS is clearly written assuming
the use of .class files. As just it does not belong in a "Java *Language*
Specification"; it perhaps better belongs in the VM spec. We should not
let it constrain our implementation choices.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/~per/