Andrew Zhang wrote:
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. :)
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?
--
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]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
