Re: Trouble building gcj 4.8.1

Well, the issue is I'm not sure how to implement them correctly. 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. Perhaps it doesn't matter all that much, but if String is
not special it'd be nice to move to the classpath version which seems
to be much more thorough.

On Wed, Jul 3, 2013 at 3:43 PM, Mike Hearn <[email protected]> wrote:
> Well, the issue is I'm not sure how to implement them correctly. 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. Perhaps it
> doesn't matter all that much, but if String is not special it'd be nice to
> move to the classpath version which seems to be much more thorough.
>
>
> On Tue, Jul 2, 2013 at 4:53 PM, Bryce McKinlay <[email protected]> wrote:
>>
>> On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley <[email protected]> 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
>
>