Re: Patch: RFC: version compiled classes

[Bryce McKinlay <mckinlay at redhat dot com>]

Tom Tromey wrote:

> On irc Bryce suggested that we should instead version .so files, not
> single classes.  I do think that would be better, I just didn't see a
> way to go about doing it.  There are 3 cases:
>
> * GNU ld systems that use .jcr.  I think we would have to modify the
>  linker for this.  It would have to reject attempts to link together
>  classes with different versions.
Ahh, good point - we don't want to go there. OK, particularly given that 
someone could still link random .o files together into an .so, I'm now 
convinced that versioning each class is fine.

>  It seems like somehow it would
>  have to be backward compatible as well, since a given system
>  ordinarily ships a single 'ld' but may ship multiple versions of
>  gcj.
>
> * Non-GNU ld systems.  On these systems we register classes using
>  static constructors.  I couldn't think of any way to accommodate
>  these systems; they would always have to be per-class.
>  
I am hoping that we can find a way to accomodate such systems when we 
move to "symbolic" class metadata. For ELF systems, it should be 
possible to make opening a .so to determine what classes it contains 
very fast, by grouping the essential metadata together in the .jcr 
section and perhaps implementing a custom, bare-bones ELF-loader. I 
think its important to have this capability so that we can make the 
BC-ABI more user-friendly and make the dbtool functionality happen 
automatically.

> Index: libjava/ChangeLog
> from  Tom Tromey  <tromey@redhat.com>
>
> 	* java/lang/Class.h (next): Updated documentation.
> 	* java/lang/natClassLoader.cc (_Jv_RegisterClasses): Use
> 	_Jv_AbiRecognized.
>  
_Jv_CheckABIVersion might be a better name?

Regards

Bryce