Trouble building gcj 4.8.1

[Bryce McKinlay]

On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley <aph@redhat.com> wrote:
> On 06/25/2013 03:15 PM, Mike Hearn wrote:
>>> I'm trying to find out what you want to do to java.lang.String.  Tell me
>>> that, and we'll take it from there.
>>
>> At the moment, supporting the methods that take java.nio.Charset. I'm
>> going to try and just hack it up with something like this:
>>
>>   public String(byte[] data, int offset, int count, Charset encoding)
>>     throws UnsupportedEncodingException
>>   {
>>     init (data, offset, count, encoding.name());
>>   }
>>
>> and then the same for getBytes().
>
> OK.  I think you can just add those methods.
>
>> But in general I anticipate that I'll continue to hit stubs or quirks
>> in classpath so I'm trying to figure out how best to reach my goal,
>> which will likely involve fixing up various things along the way. For
>> instance, my first yak-shaving goal is to run the test suite for the
>> core library of this app and then hack/fix until all the tests pass.
>
> In general, we follow Classpath except for a few core classes -- and
> String is one of those.  Major hacking on core classes requires compiler
> changes, so I strongly recommend you don't do that.  For example, better
> not add any fields.  But in general for almost the whole class library
> you won't have so much trouble.

I think it's only java.lang.Object and java.lang.Class that are
"special" - i.e. could conceivably require compiler changes if you
changed the field layout. As far as I can recall, String isn't really
treated specially in any way.

There should be no problem at all adding those methods and I would
encourage you to go ahead and submit a patch.

Bryce