You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Jimmy, Jing Lv (JIRA)" <ji...@apache.org> on 2006/09/04 11:04:22 UTC
[jira] Created: (HARMONY-1375) [classlib][net]Refine native code
interface of setSocketOption
[classlib][net]Refine native code interface of setSocketOption
--------------------------------------------------------------
Key: HARMONY-1375
URL: http://issues.apache.org/jira/browse/HARMONY-1375
Project: Harmony
Issue Type: Improvement
Components: Classlib
Reporter: Jimmy, Jing Lv
Priority: Minor
According to discussion on Harmony 1295, a refine may be made on native method setSocketOption of java.net. More discussion on this (if necessary/howto) is welcome.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1375) [classlib][net]Refine native code
interface of setSocketOption
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1375?page=comments#action_12432803 ]
Alexey Varlamov commented on HARMONY-1375:
------------------------------------------
Just for the record, copy-pasting suggestions expressed on the dev-list.
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 (until runtime)...
> [classlib][net]Refine native code interface of setSocketOption
> --------------------------------------------------------------
>
> Key: HARMONY-1375
> URL: http://issues.apache.org/jira/browse/HARMONY-1375
> Project: Harmony
> Issue Type: Improvement
> Components: Classlib
> Reporter: Jimmy, Jing Lv
> Priority: Minor
>
> According to discussion on Harmony 1295, a refine may be made on native method setSocketOption of java.net. More discussion on this (if necessary/howto) is welcome.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-1375) [classlib][net]Refine native code
interface of setSocketOption
Posted by "Alexey Varlamov (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-1375?page=comments#action_12432807 ]
Alexey Varlamov commented on HARMONY-1375:
------------------------------------------
The second variant does not require significant efforts and would provide basic type safety. Dropped overhead of boxing/unboxing of parameters would be a pleasing bonus.
So I suggest to follow #2 for now and return to #1 later if/when needed.
> [classlib][net]Refine native code interface of setSocketOption
> --------------------------------------------------------------
>
> Key: HARMONY-1375
> URL: http://issues.apache.org/jira/browse/HARMONY-1375
> Project: Harmony
> Issue Type: Improvement
> Components: Classlib
> Reporter: Jimmy, Jing Lv
> Priority: Minor
>
> According to discussion on Harmony 1295, a refine may be made on native method setSocketOption of java.net. More discussion on this (if necessary/howto) is welcome.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira