RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl

[Seán Coffey]

On 01/10/2013 14:51, Daniel Fuchs wrote:
> On 10/1/13 3:09 PM, Seán Coffey wrote:
>> Since I'm only creating a dummy socketImpl to test the
>> classcastexception, no real networking stack is in place here. I'm
>> catching the NPE that would be thrown from the native
>> Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the
>> underlying socket passed to it is null.
>>
>> C:\tmp>java CustomSocketImplFactory
>> Created Socket[addr=null,port=0,localport=0]
>> Exception in thread "main" java.lang.NullPointerException: socket is 
>> null
>>          at java.net.TwoStacksPlainSocketImpl.socketAccept(Native 
>> Method)
>
> That's what I would have expected from your previous changeset.
>
> But you're no longer passing null - right? Now you're passing
> an instance of CustomSocketImpl.
>
> So where does the NPE come from? Could it be because you should
> be calling:
>    ServerSocket.setSocketImplFactory(new CustomSocketImplFactory());
> and not:
>    Socket.setSocketImplFactory(new CustomSocketImplFactory()); ?
The original bug stemmed from a custom socket Impl interacting with the 
JDK ServerSocket Impl. If I move both Socket and ServerSocket factory 
implementations over to use the custom Impl, the testcase doesn't get to 
walk through the JDK serverSocket code and the ClassCastException is not 
seen.

The NPE seen is coming from down in the native stack when the JDK 
ServerSocket is running through accept request (from our client socket). 
I don't think it's an issue for this case.

line 611 : 
http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c

regards,
Sean.
> Or should you call both?
>
> best regards,
>
> -- daniel
>
>
>>
>> Regards,
>> Sean.
>>
>>>
>>> Or is that going to hide future bugs?
>>>
>>> best regards
>>>
>>> -- daniel (not a reviewer)
>>
>