Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of vvgorr@gmail.com designates
 64.233.166.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=EgkNuZ6cOFho+Xxvjplh1S/i0o+LhLEFhJdULmH6pMiL8ebXeBiLTOsfBORDg8ISV/KwYV0KlTy85b6ZQ5KjtxcgxvJVvlnqL+hjECMb1n5SgB6x9+YZIHDxKLXMJ+3rkFQg9vRDf4zSrWT8hreN+2ZmKO0FR1VLruyJkEHjcIw=
Message-ID: <23951bd90607122231w7c77860m529d3069f950139a@mail.gmail.com>
Date: Thu, 13 Jul 2006 12:31:23 +0700
From: "Vladimir Gorr" <vvgorr@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815)
 [classlib][nio] Refine implConfigureBlocking(boolean) method of
 DatagramChannel and SocketChannel.)
In-Reply-To: <44B5BF3F.8050409@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9782_32842123.1152768683336"
References: <44B5BF3F.8050409@gmail.com>

------=_Part_9782_32842123.1152768683336
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/13/06, Jimmy, Jing Lv <firepure@gmail.com> wrote:
>
> Hi:
>
>     I'd like to raise the topic on I18N of native code. As discussed
> about patch-815, we found there are exceptions thrown by native code
> with un-internationalized error message. To resolve this problem, there
> may be two solutions:
>
> 1) make native code return error code instead of throw exceptions, and
> let Java code deal with these errors. This seems pretty good, and also
> resolve such problems like 815, but require much more effort to refactor
> all native and Java codes. What's more, as some native methods do not
> return an integer at all, we may add an output parameter to them, at
> least for network-related luni/nio, there are about 10 methods like this.
>
> 2) As it is still easy for native code to call Java code, so rewrite
> error-message-lookup native method to lookup internationalized message,
> e.g., call MsgUtil.getString(). This refactor may be easy, but to
> JIRA-815 and other message-dependent Java code, it do no help. So it
> still requires other refactoring, e.g., return error code in some
> situation like suggested in (1).


Indeed we need to i18d the native code to resolve this issue. I'd suggest to
use the log4cxx & resource bundle approach
for doing this. This one can be suitable for both VMs & API natives. I'm
going to create new thread to discuss this approach.

Thanks,
Vladimir.

Another solution can be: catch exceptions on Java code, replace its
> message, and throw out again, this may be too ugly, so I do not suggest
> so.
>
> Any suggestions? Thanks!
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

------=_Part_9782_32842123.1152768683336--