Harmony
  1. Harmony
  2. HARMONY-27

The network related channels in java.nio.channels are not implemented

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Classlib
    • Labels:
      None

      Description

      The following classes defined by Java Spec 5.0 in java.nio.channels are not included in the class library code
      public abstarct class java.nio.channels.DatagramChannel
      public abstract class java.nio.channels.ServerSocketChannel
      public abstract class java.nio.channels.SocketChannel

      1. java.net.JPG
        62 kB
        Paulex Yang
      2. Nio-net Refactoring.jpg
        107 kB
        Paulex Yang
      3. FileDescriptorHandler.java
        1 kB
        Paulex Yang
      4. INetworkSystem.java
        7 kB
        Paulex Yang
      5. OSNetworkSystem.java
        23 kB
        Paulex Yang
      6. OSNetworkSystem.c
        71 kB
        Paulex Yang
      7. OSNetworkSystem.h
        12 kB
        Paulex Yang
      8. OSNetworkSystemWin32.c
        6 kB
        Paulex Yang
      9. NetworkSystem.zip
        46 kB
        Richard Liang
      10. NetworkSystem-linux.zip
        35 kB
        Richard Liang
      11. hynio_patch.txt
        3 kB
        Richard Liang
      12. luni.patch
        118 kB
        Paulex Yang
      13. make.patternsets.patch
        0.5 kB
        Paulex Yang
      14. nio.patch
        139 kB
        Paulex Yang

        Issue Links

          Activity

          Hide
          Tim Ellison added a comment -

          Verified by Paulex.

          Show
          Tim Ellison added a comment - Verified by Paulex.
          Hide
          Paulex Yang added a comment -

          looks fine, thank you, Tim

          Show
          Paulex Yang added a comment - looks fine, thank you, Tim
          Hide
          Tim Ellison added a comment -

          Paulex,

          Thanks for the numerous patches and improvements – I believe that this issue can be marked resolved now.
          Patches applied to the NIO module at repo revision 392243.

          Please check that the code was applied as you expected.

          Show
          Tim Ellison added a comment - Paulex, Thanks for the numerous patches and improvements – I believe that this issue can be marked resolved now. Patches applied to the NIO module at repo revision 392243. Please check that the code was applied as you expected.
          Hide
          Paulex Yang added a comment -

          Pls. try the latest patches for this issue. These patches includes java files for network related channels, and some relevant refactoring of java.net classes in LUNI. Hopefully these patches can resolve the issue now.

          Show
          Paulex Yang added a comment - Pls. try the latest patches for this issue. These patches includes java files for network related channels, and some relevant refactoring of java.net classes in LUNI. Hopefully these patches can resolve the issue now.
          Hide
          Paulex Yang added a comment -

          Hi, Tim, I think this issue has not been resolved yet. Because the patches for the three network channel's java codes haven't been attached yet. It has been lasting so long because I am waiting for the NIO/LUNI refactoring(JIRA-92, 193, etc). So I suggest to reopen this issue, and because 193 has been closed, now I can attach the Java code patches.

          Show
          Paulex Yang added a comment - Hi, Tim, I think this issue has not been resolved yet. Because the patches for the three network channel's java codes haven't been attached yet. It has been lasting so long because I am waiting for the NIO/LUNI refactoring(JIRA-92, 193, etc). So I suggest to reopen this issue, and because 193 has been closed, now I can attach the Java code patches.
          Hide
          Tim Ellison added a comment -

          Closing resolved issue – no response from reporter, so assuming ok.

          Show
          Tim Ellison added a comment - Closing resolved issue – no response from reporter, so assuming ok.
          Hide
          Tim Ellison added a comment -

          Richard,

          Thanks, I've checked and applied the enhancements you provided. Please ensure that they have been applied as you expected.

          I realize that there is more refactoring required based on Paulex's comments, please can you put those into a new JIRA issue (linked to this if you want) to ensure we can track the completion of coherent, individual steps. Of course, if there is a problem with this patch-set feel free to reopen this issue.

          Regards,
          Tim

          Show
          Tim Ellison added a comment - Richard, Thanks, I've checked and applied the enhancements you provided. Please ensure that they have been applied as you expected. I realize that there is more refactoring required based on Paulex's comments, please can you put those into a new JIRA issue (linked to this if you want) to ensure we can track the completion of coherent, individual steps. Of course, if there is a problem with this patch-set feel free to reopen this issue. Regards, Tim
          Hide
          Richard Liang added a comment -

          Hello Tim,

          Thanks a lot for your kind comments.

          • why do you need to #include <stdlib.h> in OSNetworkSystem.c ? I removed it and everything compiled ok.
            ==> yes. we do not need the 'include' statement. Sorry
          • there needs to be a patch to the hynio.def file to export the OSNetworkSystem functions.
            ==> I have attached the patch for hynio.def called hynio_patch.txt
          • as you point out, there needs to be Linux equivalents for these.
            ==>>They are attached called NetworkSystem-linux.zip
          Show
          Richard Liang added a comment - Hello Tim, Thanks a lot for your kind comments. why do you need to #include <stdlib.h> in OSNetworkSystem.c ? I removed it and everything compiled ok. ==> yes. we do not need the 'include' statement. Sorry there needs to be a patch to the hynio.def file to export the OSNetworkSystem functions. ==> I have attached the patch for hynio.def called hynio_patch.txt as you point out, there needs to be Linux equivalents for these. ==>>They are attached called NetworkSystem-linux.zip
          Hide
          Tim Ellison added a comment -

          Thanks for doing this work Richard.

          I've had a look at your code. The definition of the INetworkSystem is good, and fits in with the file system and memory system we already have.

          Just a couple of questions:

          • why do you need to #include <stdlib.h> in OSNetworkSystem.c ? I removed it and everything compiled ok.
          • there needs to be a patch to the hynio.def file to export the OSNetworkSystem functions.
          • as you point out, there needs to be Linux equivalents for these.

          I won't commit these changes until the above issues are addressed.

          Show
          Tim Ellison added a comment - Thanks for doing this work Richard. I've had a look at your code. The definition of the INetworkSystem is good, and fits in with the file system and memory system we already have. Just a couple of questions: why do you need to #include <stdlib.h> in OSNetworkSystem.c ? I removed it and everything compiled ok. there needs to be a patch to the hynio.def file to export the OSNetworkSystem functions. as you point out, there needs to be Linux equivalents for these. I won't commit these changes until the above issues are addressed.
          Hide
          Richard Liang added a comment -

          Hello Tim,

          Here is the implementation of network system. Would you please help to verify it? Thanks a lot.

          Implementation Details:
          1. Three classes are added in com.ibm.platform:
          com.ibm.platform.FileDescriptorHandler
          com.ibm.platform.INetworkSystem
          com.ibm.platform.OSNetworkSystem
          2. Two classes are modified a bit:
          com.ibm.platform.OSComponentFactory
          com.ibm.platform.Platform
          3. New added Native code in win.IA32/nio:
          helpers.h, helpers.c, nethelp.h, nethelp.c,
          OSNetworkSystem.h, OSNetworkSystem.c, OSNetworkSystemWin32.c
          socket.h, socket.c
          makefile is modified accordingly.

          The native source is only for win.IA32. I will post linux version soon.

          Show
          Richard Liang added a comment - Hello Tim, Here is the implementation of network system. Would you please help to verify it? Thanks a lot. Implementation Details: 1. Three classes are added in com.ibm.platform: com.ibm.platform.FileDescriptorHandler com.ibm.platform.INetworkSystem com.ibm.platform.OSNetworkSystem 2. Two classes are modified a bit: com.ibm.platform.OSComponentFactory com.ibm.platform.Platform 3. New added Native code in win.IA32/nio: helpers.h, helpers.c, nethelp.h, nethelp.c, OSNetworkSystem.h, OSNetworkSystem.c, OSNetworkSystemWin32.c socket.h, socket.c makefile is modified accordingly. The native source is only for win.IA32. I will post linux version soon.
          Hide
          Paulex Yang added a comment -

          Following the JNI interfaces I attached before, here goes the native implementations. The OSNetworkSystem.h is the JNI header file generated by javah, and OSNetworkSystem.c is portable implementation, OSNetworkSystemWin32.c is the complement of OSNetworkSystem.c, which are win32 platform dependent.

          Most (I guess 90%) of these methods are refactored from the original socket native codes located in luni component, including simpl.c, psimpl2.c, pssimpl.c, pmsimpl.c and pdsimpl.c (and for sure, these files can be replaced if relevant Java files are done), the modification to these methods only limited to change name to Java_java_net_**Socket_** to Java_com_ibm_platform_OSNetworkSytem_***, etc. Others are added to meet channels' needs.

          Those methods in OSNetworkSystem.c depend heavily on the port library, so that they should be compiled on different platform easiy without change, I've tested on RedHat 9 and Win32. Further more, the two methods in OSNetworkSystemWin32.c are platform specific just because there are some pitfalls in port library, hope we can get around it later.

          There are still some TODOs left to use these files
          1. Java codes
          2. Some minor changes to other native files, i.e., the method declarations within original sockect.c should be moved to socket.h
          3. The JCL_CACHE_GET/SET macros using is not refactor yet, and temporarily I work around it by using reflection directly, and the nethelp.c needs some straightforward modification to add these reflection helper methods. I will attach a patch later to refactor the caching mechanism and avoid performance regression.

          Show
          Paulex Yang added a comment - Following the JNI interfaces I attached before, here goes the native implementations. The OSNetworkSystem.h is the JNI header file generated by javah, and OSNetworkSystem.c is portable implementation, OSNetworkSystemWin32.c is the complement of OSNetworkSystem.c, which are win32 platform dependent. Most (I guess 90%) of these methods are refactored from the original socket native codes located in luni component, including simpl.c, psimpl2.c, pssimpl.c, pmsimpl.c and pdsimpl.c (and for sure, these files can be replaced if relevant Java files are done), the modification to these methods only limited to change name to Java_java_net_** Socket_ ** to Java_com_ibm_platform_OSNetworkSytem_***, etc. Others are added to meet channels' needs. Those methods in OSNetworkSystem.c depend heavily on the port library, so that they should be compiled on different platform easiy without change, I've tested on RedHat 9 and Win32. Further more, the two methods in OSNetworkSystemWin32.c are platform specific just because there are some pitfalls in port library , hope we can get around it later. There are still some TODOs left to use these files 1. Java codes 2. Some minor changes to other native files, i.e., the method declarations within original sockect.c should be moved to socket.h 3. The JCL_CACHE_GET/SET macros using is not refactor yet, and temporarily I work around it by using reflection directly, and the nethelp.c needs some straightforward modification to add these reflection helper methods. I will attach a patch later to refactor the caching mechanism and avoid performance regression.
          Hide
          Tim Ellison added a comment -

          Thanks Paulex – this makes sense. It fits in with the design of FileChannels that are under development already.

          Can you attach the native code that goes with this? Then I can create the SocketChannels and refactor the regular IO to use the o.a.h.net package.

          Show
          Tim Ellison added a comment - Thanks Paulex – this makes sense. It fits in with the design of FileChannels that are under development already. Can you attach the native code that goes with this? Then I can create the SocketChannels and refactor the regular IO to use the o.a.h.net package.
          Hide
          Paulex Yang added a comment -

          This files demonstrate what I mean on the JNI interface, which encapsulate network relevant functions for both NIO and LUNI component. Significant part of the method declarations are refactored from current Harmony java.net JNI methods, others are added to support NIO extension.

          Show
          Paulex Yang added a comment - This files demonstrate what I mean on the JNI interface, which encapsulate network relevant functions for both NIO and LUNI component. Significant part of the method declarations are refactored from current Harmony java.net JNI methods, others are added to support NIO extension.
          Hide
          Paulex Yang added a comment -

          the proposed net/nio refactory result diagram

          Show
          Paulex Yang added a comment - the proposed net/nio refactory result diagram
          Hide
          Paulex Yang added a comment -

          the current java.net class diagram

          Show
          Paulex Yang added a comment - the current java.net class diagram
          Hide
          Paulex Yang added a comment -

          my proposed solution:

          1. Refactor the java.net

          Currently, the Harmony's socket structur is as below(red means API classes, others are package private). I will attach the diagram to Jira.

          I proposed to refactor to three packages like this:

          java.net: for sure includes All API classes, and includes them only
          public class Socket
          public class ServerSocket
          public abstract class SocketImpl
          public class DatagramSocket
          public class MulticastSocket extends DatagramSocket
          public abstract class DatagramSocketImpl

          org.apache.harmony.net: all implementation classes with a factory
          public class SocketImplProvider
          class PlainSocketImpl extends SocketImpl
          class PlainSocketImpl2 extends PlainSocketImpl
          class PlainServerSocketImpl extends PlainSocketImpl
          class PlainDatagramSocketImpl extends DatagramSocketImpl
          class PlainMulticastSocketImpl extends PlainDatagramSocketImpl
          some relevant small classes(Socks4Message, GenericIPMreq)

          org.apache.platform: currently, this package includes native file system and memory management interface, so it is a good place to include the native network interface, the INetworkSystem will encapsulate all JNI interfaces.
          public interface INetworkSystem
          public class OSNetworkSystem implements INetworkSystem

          2. Implement java.nio
          Now it is ready to implement NIO network channels based on it:
          java.nio:
          public abstract class SocketChannel
          public abstract class ServerSocketChannel
          public abstract class DatagramSocketChannel
          class SocketChannelImpl
          class ServerSocketImpl
          class DatagramSocketChannelImpl
          class SocketAdapter
          class ServerSocketAdapter
          class DatagramSocketAdapter

          I will attach the result diagram into JIRA, too

          3. Modulize them
          According to the current Harmony modulization, propose to modify the modulization as follows:
          luni exports: java.net, org.apache.harmony.net, org.apache.harmony.platform(move from nio to luni, and export it)
          nio exports: java.nio

          Show
          Paulex Yang added a comment - my proposed solution: 1. Refactor the java.net Currently, the Harmony's socket structur is as below(red means API classes, others are package private). I will attach the diagram to Jira. I proposed to refactor to three packages like this: java.net: for sure includes All API classes, and includes them only public class Socket public class ServerSocket public abstract class SocketImpl public class DatagramSocket public class MulticastSocket extends DatagramSocket public abstract class DatagramSocketImpl org.apache.harmony.net: all implementation classes with a factory public class SocketImplProvider class PlainSocketImpl extends SocketImpl class PlainSocketImpl2 extends PlainSocketImpl class PlainServerSocketImpl extends PlainSocketImpl class PlainDatagramSocketImpl extends DatagramSocketImpl class PlainMulticastSocketImpl extends PlainDatagramSocketImpl some relevant small classes(Socks4Message, GenericIPMreq) org.apache.platform: currently, this package includes native file system and memory management interface, so it is a good place to include the native network interface, the INetworkSystem will encapsulate all JNI interfaces. public interface INetworkSystem public class OSNetworkSystem implements INetworkSystem 2. Implement java.nio Now it is ready to implement NIO network channels based on it: java.nio: public abstract class SocketChannel public abstract class ServerSocketChannel public abstract class DatagramSocketChannel class SocketChannelImpl class ServerSocketImpl class DatagramSocketChannelImpl class SocketAdapter class ServerSocketAdapter class DatagramSocketAdapter I will attach the result diagram into JIRA, too 3. Modulize them According to the current Harmony modulization, propose to modify the modulization as follows: luni exports: java.net, org.apache.harmony.net, org.apache.harmony.platform(move from nio to luni, and export it) nio exports: java.nio

            People

            • Assignee:
              Tim Ellison
              Reporter:
              Paulex Yang
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development