On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
FWIW, a while back I prototyped an "in tre
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
Florian Weimer wrote:
:
I've been wondering for a while if it is possible (with reasonable
additional effort) to add new socket and socket address classes without
patching the JDK sources.
No, it's not. :-)
Florian Weimer wrote:
[Extensible socket types]
:
Do you think it would be possible to do this out-of-tree? I think I
could port my client code to SocketChannel. (If I require a customized
JDK, it will raise a few eyebrows.)
It should be feasible but it would likely be a platform/provi
On 08/26/2008 09:20 AM, Christopher Hegarty - Sun Microsystems Ireland wrote:
On 08/26/08 14:41, David M. Lloyd wrote:
On 08/20/2008 04:37 AM, Alan Bateman wrote:
FWIW, a while back I prototyped an "in tree" solution for
SocketChannel. The primary motive was to allow for Sockets Direct
Protoco
David M. Lloyd wrote:
:
I just mean, what would be the benefit of using SocketAddress rather
than using a String or Path directly? You can avoid the difficulties
of extending SocketAddress by simply not using it.
If the protocol or socket address is specified by String then the
implementation
On 08/26/2008 11:12 AM, Alan Bateman wrote:
David M. Lloyd wrote:
:
I just mean, what would be the benefit of using SocketAddress rather
than using a String or Path directly? You can avoid the difficulties
of extending SocketAddress by simply not using it.
If the protocol or socket address is
David M. Lloyd wrote:
:
No, the concern is just that the SocketAddress hierarchy is just kind
of broken (the indicators are the fact that it's an empty abstract
class, and that anywhere it's used, it's immediately casted to a more
specific type). You could change this, but it still seems to m
