This content has been marked as final. Show 9 replies
Great, we can get rid of the Java Community Process altogether. Just everybody think of a class name, write it, and shove it in. No matter that nobody else knows what it's supposed to do, or whether it actually does it. Saves all that messy testing too.
are you perhaps looking for http://download.oracle.com/javase/6/docs/api/java/net/ServerSocket.html#accept%28%29 ?
No, I know the Java API pretty well. I'm thinking of a nice way to get rid of all the thread plumbing that goes with the current Network API. No more spawning a thread explicitly to handle the ServerSocket.accept call.
Check this out:
SocketListener sl = new SocketListener(80);
then when you get an event your interface gets the callback"
public void networkEventCallback(NetEvent ne)
// do your code here
I'm not suggesting anything of the sort; merely asking if the JCP has already considered such a proposal and if not I could create/submit the idea to the correct JCP.
I hope it won't get approved. It would be a terrible day if everything AND the kitchen sink would be allowed into the JDK, it would grow so much out of proportions nobody would understand it anymore.
you can essentially do this with the new async io api in jdk 7, right (where CompletionHandler is similar to your SocketListener)?
I'm not suggesting anything of the sortYou did exactly what I said. You mentioned a class name, gave no specification or even description, offered to put it into the JDK with no further consultation, and you didn't even mention the JCP. QED
merely asking if the JCP has already considered such a proposalNo you weren't, but now that you are, ask them. This isn't the JCP.
There is a repository online (can't mention which one) with a C# server that has a SocketListener implementation, that works fantastic... so, I thought wow, I'd love that.
1st issue: I had to override accept() in the ServerSocket, as I needed to create my own Socket class that inherited from Socket.
2nd issue: The socketConnected event did not work because the socket connects within it's constructor and I couldn't add the socket listener before the constructor, I think if you build your own constructor you should be able to though, otherwise a constructor to initialize the object and a connect() method to create the connection.
3rd issue: The socketDisconnected event will not work because the isBound(), isConnected() and isClosed() are not reliable enough to pick up if the socket has been closed or reset. You will have to build some sort of heartbeat method to check the socket is closed, and that requires sending/receiving values through the socket, and that may create issues depending on one's client/server setup.
4th issue: If you intend on creating a socketWrite/Read event, this might have to be implemented on the I/O streams.
I worked on it for about an hour, so I didn't really go into it too deeply. These where the issues I came across when doing a very basic SocketListener, I then gave up.
isBound(), isConnected(), isClosed aren't unreliable. They just aren't intended to tell you the state of the connection. They are intended to tell you about the state of this Socket, i.e. basically which methods have been called on this socket, and they do that with 100% reliability. It isn't possible to provide methods that tell you about the state of the connection in TCP: the only way to discover that is with a Selector, or by reading or writing it.