On Dec 12, 2006, at 2:40 AM, Roman Kennke wrote:
Hi there,
I am not happy with the current situation wrt to the Socket related VM
interface. AFAICS, we have three layers of abstraction here:
- On API level we have the Socket/SocketImpl/SocketImplFactory stuff.
- Below this we have PlainSocketImpl and VMPlainSocketImpl et al.
- On the native side there is some kind of target layer too.
At least one of these layers seems superfluous. The VMSocketImpl class
seems to mostly map the methods from the SocketImpl class again.
I'd like to see the native "target layer" go away. I think the
minimum required to support user threads and blocking calls (like
what we do in NIO) should suffice.
Are there any objections to boiling down the VM interface to something
like:
class VMSockets
{
SocketImplFactory getSocketImplFactory();
DatagramSocketImplFactory getDatagramSocketImplFactory();
}
I think I see where you're going with this, and I agree that it would
be cleaner. The line where VMs need to take over, and where the
reference implementation will suffice, is a little blurry at the
moment. Defining it better should help out.
Of course, comments on how well this works for VM implementors who
can't use the POSIXy RI would be well appreciated here.
Thanks.
