PR java/19285: Interfaces not initialized by static field access

[Bryce McKinlay]

Andrew Haley wrote:

>Tom Tromey writes:
> > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
> > 
> > Andrew> The idea is that rather than calling _Jv_InitClass for every static
> > Andrew> field we call _Jv_ResolvePoolEntry instead.  We also cache these
> > Andrew> locally so that _Jv_ResolvePoolEntry is only called once.
> > 
> > I think if we add a new function to the exported interface, then we
> > must rev the BC ABI version that we claim to be generating.  The
> > reason for this is that the gcj with this patch will generate code
> > which won't work with an earlier libgcj.  So, I think we must increase
> > the revision.
> > 
> > (I suppose the counter argument is that such objects will simply fail
> > to link.. ?)
>
>The counter argument is that, of necessity, the ABI of gcc HEAD is
>experimental; to bump the ABI # on every minor change is unnecessary.
>In the case of a released gcc it's a different story.
>  
>

Yes, we should not be changing the ABI version number with every minor 
change, however, experimental versions should have a different version 
number to released versions - ie we should bump the version number the 
first time such a change is made on HEAD after a release. This will 
avoid confusion when binaries made with HEAD are accidentally run on an 
older release version.

How about something like this? Or would it be better to explicitly 
define each different version somewhere?

Bryce


-------------- next part --------------
A non-text attachment was scrubbed...
Name: java-bcabi-ver.patch
Type: text/x-patch
Size: 2339 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20050503/c51993ca/attachment.bin>