Keep in mind that a workaround for this is to explicitly qualify the
method with the desired class (ie. the one where the method is actually
defined).
In other words, instead of
Encoder8859_1.loadTable()
in the source code, use
EncoderEightBitLookup.loadTable()
The only problem I see with this approach is if EncoderEightBitLookup is
not accessible when Encoder8859_1 is. Then an alternative workaround
would be to modify Encoder8859_1 by adding this method:
public static void loadTable() { super.loadTable(); }
I'm not familiar with the ORP code, but these workarounds shouldn't be
too hard.
Do you want me to file a PR for the gcc bug? I've yet to get a working
compile of gcj on my cygwin box, so I'm not sure how well I would do on
bug reporting.
Mark Wielaard wrote:
>
> That (and the example) seems to make sense. But it also means that we
> don't have one bug in jikes, but two bugs, one in ORP and one in gcj
> byte code generation. Sigh.
>
> That basicly means we don't recommend jikes 1.15a for this Classpath
> release and ORP 1.0.9, or we wait for a new ORP release with a fix.
> Hmmmm. I would opt for releasing now and adding a note about this
> problem (with newer versions of jikes and ORP) to the README/INSTALL
> file. Or we could try to produce a patch for ORP, but I am not sure that
> is very easy.
>
> Cheers,
>
> Mark
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
