On 8/29/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/8/29, Andrew Zhang <[EMAIL PROTECTED]>: > On 8/28/06, Alexey Varlamov (JIRA) <[EMAIL PROTECTED]> wrote: > > > > [classlib][net] flaw in setReuseAddrAndReusePort() > > -------------------------------------------------- > > > > Key: HARMONY-1295 > > URL: http://issues.apache.org/jira/browse/HARMONY-1295 > > Project: Harmony > > Issue Type: Bug > > Components: Classlib > > Reporter: Alexey Varlamov > > Priority: Critical > > > > > > The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM > > : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f->get_class()))' > > failed. > > The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls > > to > > PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean > > value, but underlying native code treats this value as Integer. > > > > Quickfix must be straightforward enough, but I inclined to blame the > > design of INetworkSystem.[set|get]SocketOption() as the actual root of the > > evil. The problem is that this API conceals the details of contract for > > particular options, and a client have to guess which type of value to pass. > > > I think it's "determine", not "guess". :) > > And the implementation is basically an ugly switch sorting requests out to > > setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor > > this? > > > Any proposals? Thanks! > Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*?
Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with
specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc.
It's a design problem. The legacy design provides simple & unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods,
which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity...
Agree. For this case, at least, we could use "booleanValue" for Boolean and "intValue" for Integer. :) --
Regards, Alexey --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrew Zhang China Software Development Lab, IBM
