harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Thu, 13 Jul 2006 03:34:23 GMT

     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).

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

View raw message