harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Date Tue, 29 Aug 2006 06:38:01 GMT
On 8/29/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> 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_*?


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