Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of alexey.v.varlamov@gmail.com
 designates 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=j0fVu+yXPb4ndA8RP5vxAH7clIBO6nshxkD4woiZa7PrskpETinZTZJBooNXbNXWGoSEh2N1MdUZ04l5arnnOWefoiGO6RNpWbE9xsOKfXjBOK9L8PKHrztqYNZEv9TNzB37iSp+25+L5SL+oXW5M+Uc+f2/z2mXgMIfmo0+Ie8=
Message-ID: <f944d83d0608282257x1e651f5wc39563c20e6b45fe@mail.gmail.com>
Date: Tue, 29 Aug 2006 12:57:07 +0700
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in
 setReuseAddrAndReusePort()
In-Reply-To: <4d0b24970608281841y7a1b370ax93c62abac750c183@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <657651.1156763422386.JavaMail.jira@brutus>
	 <4d0b24970608281841y7a1b370ax93c62abac750c183@mail.gmail.com>

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