Harmony
  1. Harmony
  2. HARMONY-1375

[classlib][net]Refine native code interface of setSocketOption

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Tim Ellison added a comment -

          Has been no further discussion on this topic.

          Show
          Tim Ellison added a comment - Has been no further discussion on this topic.
          Hide
          Alexey Varlamov added a comment -

          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.

          Show
          Alexey Varlamov added a comment - 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.
          Hide
          Alexey Varlamov added a comment -

          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)...

          Show
          Alexey Varlamov added a comment - 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)...

            People

            • Assignee:
              Tim Ellison
              Reporter:
              Jimmy, Jing Lv
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development