harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Date Tue, 29 Aug 2006 05:57:07 GMT
2006/8/29, Andrew Zhang <zhanghuangzhu@gmail.com>:
> On 8/28/06, Alexey Varlamov (JIRA) <jira@apache.org> 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_*? Let's have a clean API with
specialized methods as XXXSocket classes have: setTTL(int) ,
isReuseAddress() etc.

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

--
Regards,
Alexey

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


Mime
View raw message