Trouble building gcj 4.8.1
Tue Jul 2 14:53:00 GMT 2013
On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley <email@example.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.
More information about the Java