Gary Benson wrote:
Gary> I agree. But in the same way we probably can't guarantee
Gary> compatibility between gcj-4.0.0-x and gcj-4.0.0-y.
We can always make mistakes... but we do try to guarantee that we
don't break compatibility in this case, even in the 4.0.x series.
Ah, ok. Is the BC-ABI immune to things like adding extra
members/methods to classes then?
Yes. In general the BC-ABI conforms to chapter 13 of the JLS.
So far, as far as I know, 4.1 can use any BC-compiled object
generated by 4.0. However, we don't want to really promise that we
won't break this in the future, as we might find some reason that we
can't keep this working.
Our hope is that starting with 4.1 we can guarantee compatibility.
If compatibility _is_ broken, will it fail gracefully?
libgcj 4.0.0 would crash if it saw a compiled class with an incompatible
version ID, but this is fixed in 4.0.1 and 4.1. Now, we will silently
refuse to load the class and fall back to the bytecode interpreter when
a native-compiled class could not be loaded for some reason.
But, I'm not sure that this is really the most "graceful" behaviour -
the user could easily be unaware that their .so did not load and wonder
why performance is bad. Other alternatives we could consider include:
1. Issue a warning before falling back to the bytecode interpreter
2. Throw a ClassFormatError/ClassNotFoundException/VerifyError
Note that this will most likely happen when you try to run a newwer
compiled class against an old runtime. In general, we will try to
preserve backwards-compatibility so that old compiled classes will
continue to work with new runtimes - although, as Tom points out, we
don't yet guarantee it.
Bryce
