Deja Vu: multiple definition of `java::lang::String::length()'?

[Bryce McKinlay]

Tom Tromey wrote:

>>>>>>"Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
>>>>>>
>
>Bryce> Maybe we should consider dropping the gcjh
>Bryce> inlining/decompilation altogether. I don't think it is really
>Bryce> very useful. It is problematic for binary compatibility, and
>Bryce> within libgcj we can just access the fields directly in the
>Bryce> cases where it matters.
>
>I'm reluctant to remove it.
>
>I do think that binary compatibility is an important feature for us
>moving forward.  I'm inclined to go with your proposal on that basis
>alone, especially given that there aren't any good counter-arguments :-)
>

Well the counter-argument is that we need to go through the libjava code 
and find all the performance-critical calls to the inline functions and 
replace them with field accesses. Some fields (like String's count 
field) will need to be made package-private so that random CNI methods 
can get at them. However, I suspect this would be a lot easier than 
changing gcjh to put an "inline" flag on each inline method declaration.

regards

Bryce.