From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27341 invoked by alias); 30 Mar 2010 18:41:10 -0000 Received: (qmail 27324 invoked by uid 22791); 30 Mar 2010 18:41:08 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_GC X-Spam-Check-By: sourceware.org Received: from mpls-qmqp-05.inet.qwest.net (HELO mpls-qmqp-05.inet.qwest.net) (63.231.195.116) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Mar 2010 18:41:02 +0000 Received: from [127.0.0.1] (unknown [70.58.238.194]) by mpls-qmqp-05.inet.qwest.net (Postfix) with ESMTP id 36FE3627841; Tue, 30 Mar 2010 18:40:58 +0000 (UTC) Message-ID: <4BB245AA.5020707@rhsdplanning.com> Date: Tue, 30 Mar 2010 18:41:00 -0000 From: Keith User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ahughes@redhat.com CC: java@gcc.gnu.org Subject: Re: 'java.lang.String' has no method References: <4BABA6A1.4020404@rhsdplanning.com> <4BACE60D.9080103@rhsdplanning.com> <17c6771e1003260954q21babf04v1f4f22139c692d94@mail.gmail.com> In-Reply-To: <17c6771e1003260954q21babf04v1f4f22139c692d94@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-03/txt/msg00026.txt.bz2 Resending in plain text: I was using java.net.NetworkInterface.getHardwareAddress() to get the MAC address. Work around is a JNI call (currently Windows only). I was using ResourceBundle.keySet() and ResourceBundle.containsKey() HTH, Keith Andrew John Hughes wrote: > On 26 March 2010 16:51, Keith wrote: > >> Does libgcj-4.4.0.jar support Java 1.6? > > It supports bits of it: > > http://builder.classpath.org/japi/openjdk6-libgcj.html > > And yes, there are known holes in java.net and ResourceBundle. I've > looked at implementing them a couple of times, but not yet got round > to it. > > Knowing which methods should be prioritised for implementation (i.e. > because people actually use them in real-world code) would be very > useful. And patches even more so!