harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Date Tue, 29 Aug 2006 08:15:00 GMT
Jimmy, Jing Lv wrote:
> Andrew Zhang wrote:
>> 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.  :)
>>
>
> Interesting, deep look into code, I find JNI use pointer as the field 
> ID, so field-ID of value in Boolean is the same as the one of Integer. 
> In this way the code can get a value field of Integer out of a Boolean 
> (C pointer is great! :) ). IMO, this is a mis-use but cause no error 
> until a strict check is taken. :)
> This is a bug of native code, I agree we should use "booleanValue" 
> instead of "intValue", may we raise a JIRA and fix?
Just go ahead and provide a patch for HARMONY-1295 to get this error 
fixed, and go on discussing the design issue, I agree that there are 
some things better to be improved.
>
>> -- 
>>> 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
>>>
>>>
>>
>>
>
>


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


Mime
View raw message