From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11391 invoked by alias); 3 Jul 2013 13:43:45 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 11379 invoked by uid 89); 3 Jul 2013 13:43:44 -0000 X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_GC autolearn=ham version=3.3.1 Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com) (209.85.219.54) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 03 Jul 2013 13:43:43 +0000 Received: by mail-oa0-f54.google.com with SMTP id o6so172643oag.13 for ; Wed, 03 Jul 2013 06:43:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.176.67 with SMTP id cg3mr764580obc.65.1372859022330; Wed, 03 Jul 2013 06:43:42 -0700 (PDT) Received: by 10.76.23.36 with HTTP; Wed, 3 Jul 2013 06:43:42 -0700 (PDT) In-Reply-To: References: <51C87C22.9030201@redhat.com> <51C88147.8060508@redhat.com> <51C9A389.6030000@redhat.com> <51C9A53C.20409@redhat.com> <51C9A783.40008@redhat.com> Date: Wed, 03 Jul 2013 13:43:00 -0000 Message-ID: Subject: Re: Trouble building gcj 4.8.1 From: Mike Hearn To: Bryce McKinlay Cc: Andrew Haley , GCC Java Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2013-07/txt/msg00001.txt.bz2 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 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 wrote: >> >> On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley 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 > >