Re: Trouble building gcj 4.8.1

On Wed, Jul 3, 2013 at 2:47 PM, Andrew Haley <[email protected]> wrote:
> On 07/03/2013 02:43 PM, Mike Hearn wrote:
>> if String is
>> not special it'd be nice to move to the classpath version which seems
>> to be much more thorough.
>
> Definitely.  The only problem is that no-one has had the time to ensure that
> nothing breaks.

Well, although it isn't treated specially by the compiler, libgcj's
String is also largely implemented as native CNI code, where as the
GNU Classpath one is pure Java.

Pure Java is better for most VMs, but not so much for GCJ. libgcj's
version probably performs better than the Classpath implementation
would in the GCJ environment.

> I did a
> quick hack which involves using the existing methods that take charset names
> and just calling them with Charset.forName() but I seriously doubt this is
> really fully compatible or would pass the Java test suite.

Yeah, this should more-or-less work, as long as the Charset in
question is supported by libgcj's native encoders. The native encoders
should be a lot faster than the java.nio.charset ones, too. NIO
buffers don't perform well with GCJ due to it's inability to inline
virtual calls.

Bryce