[fedora-java] New file layout for nativified rpms

[Bryce McKinlay]

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