PR java/19285: Interfaces not initialized by static field access
Tom Tromey
tromey@redhat.com
Wed May 4 18:36:00 GMT 2005
>>>>> "Bryce" == Bryce McKinlay <mckinlay@redhat.com> writes:
Bryce> Yes, we should not be changing the ABI version number with every minor
Bryce> change, however, experimental versions should have a different version
Bryce> number to released versions - ie we should bump the version number the
Bryce> first time such a change is made on HEAD after a release. This will
Bryce> avoid confusion when binaries made with HEAD are accidentally run on
Bryce> an older release version.
Yeah. I thought perhaps this patch was going in 4.0 as well, but I
don't see it there.
Anyway, I think the rule for incrementing the ABI version should be:
* C++ ABI tracks the gcc version number, so is auto-incremented each
release.
* The generated BC ABI version number should be incremented either
zero or one time between releases. In particular it should only be
incremented the first time a non-backward-compatible change is made.
* If the generated BC ABI version number is incremented on a release
branch, the corresponding increment must be applied to all newer
release branches as well. So, e.g., if we made a change next year
to 4.0.x, we would apply it to 4.1.x and 4.2.x as well.
* libgcj should recognize as many BC ABI version numbers as is
feasible.
There's still the possibility that in 4.1 we could just drop the 4.0
BC ABI entirely from libgcj. This might be simpler if we make drastic
changes. For one thing it might avoid a lot of ugly compatibility
code in the linker. No need to decide that now, of course, but it is
worth thinking about.
Bryce> How about something like this? Or would it be better to explicitly
Bryce> define each different version somewhere?
The compiler side of this looks reasonable to me.
On the runtime side I would prefer the addition of a new define and
explicit recognition of it. I think it is better to be very clear
than to try to micro-optimize this.
FWIW the system class loader patch I posted yesterday adds a couple
new sub-ABIs.
Tom
More information about the Java-patches
mailing list