Patch: RFC: version compiled classes

Bryce McKinlay mckinlay@redhat.com
Fri Jan 14 17:50:00 GMT 2005


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



More information about the Java-patches mailing list