harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Thu, 13 Jul 2006 06:06:08 GMT
On 7/13/06, Andrew Zhang <zhanghuangzhu@gmail.com> wrote:
>
> Hi Vladimir,
>
> Where exceptions should be thrown is a big question in this thread. Native
> code or Java code or mixed?



Yes, I'm aware about this. However I'd prefer to have other subject for this
thread :-).

Thanks,
Vladimir.

Shall we avoid throwing all exceptions in Harmony native code?
>
> If all exceptions are thrown in java code, there is no need to involve any
> other I18N utilities (i.e. log4cXXX).
>
> Really appreciated if anyone could summarize the advantages and
> disadvantages of these two exeption-thrown ways (by native or java).
>
> Thanks!
>
>
> On 7/13/06, Vladimir Gorr <vvgorr@gmail.com> wrote:
> >
> > 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
> > >
> > >
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message