This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Trouble building gcj 4.8.1
- From: Bryce McKinlay <bmckinlay at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Mike Hearn <mike at plan99 dot net>, GCC Java <java at gcc dot gnu dot org>
- Date: Wed, 3 Jul 2013 22:31:10 +0100
- Subject: Re: Trouble building gcj 4.8.1
- References: <CANEZrP3wxTPvx5Ky2O1qds427t9LxtSt0Bm3GntjcN63_0+3rw at mail dot gmail dot com> <CANEZrP0vTN_MAe4jOamUqKnkyXgNYJ-bsUnovANV36evGdJWPA at mail dot gmail dot com> <51C87C22 dot 9030201 at redhat dot com> <CANEZrP2woCNh4P+a-xTWqqz+PKEi01C0PU+D_TVu1jn2CeDaNw at mail dot gmail dot com> <51C88147 dot 8060508 at redhat dot com> <CANEZrP0WwGL40Vguonwb2CLvpvYmCaRTkO+wZqZ6uTGvtGxu0w at mail dot gmail dot com> <51C9A389 dot 6030000 at redhat dot com> <CANEZrP1_ChOzW9jLw=Qtx0T43GytbFZpWc7KaxGh_wFP7nD38g at mail dot gmail dot com> <51C9A53C dot 20409 at redhat dot com> <CANEZrP2VC0oc+KeQANBDu_3S32kvOyqFuQydbW8AuYN36MVgKg at mail dot gmail dot com> <51C9A783 dot 40008 at redhat dot com> <CALUNu-qbpH8omT=1uq9f0QaGUr-jO4f=bOkZ3PKbErUA9yDHKw at mail dot gmail dot com> <CANEZrP1tLxpu818cFGdgma+RVL32yRJJUOyb5m8QF=mhTZVueg at mail dot gmail dot com> <CANEZrP1JEXSjTJ+q3OvzOt80+44wVdj=vY7fVUQNUgs=oELayw at mail dot gmail dot com> <51D42B66 dot 90607 at redhat dot com>
On Wed, Jul 3, 2013 at 2:47 PM, Andrew Haley <aph@redhat.com> 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