eliminate gcjh?

Wed Mar 10 20:56:00 GMT 2004

>> Don't we run into problems when interpreting bytecode that refers to
>> these methods we're deleting?

Per> We're not deleting them in bytecode, only in native code and in gcjh
Per> (and I assume reflection).
I wasn't very clear, I just meant that it seems like we would still
need an entry in the method table for these methods, since bytecode we
load at runtime will refer to them by signature.
I still don't understand how we can eliminate the bridge methods.
Could you explain it? To me it looks like they are needed for type
safety.
For instance:
 class Base<T> {
 void add (T item) { ... }
 }
 class MySet extends Collection<String> {
 void add (String item) { ... }
 // Bridge method introduced by compiler
 void add (Object item) { add ((String) item); }
 }
 class Sneak {
 static void oops (Base b, Object x) { b.add (x); }
 }
If we eliminate the bridge method, then the user can pass a MySet to
Sneak.oops and cast any object to a String without a cast check.
I suppose we could push the cast checks into the non-bridge method.
This will come at some cost in performance, especially since cast
checks are currently slow. I'm assuming that type safety is
inviolable.
Tom