tha's true from the Java side. I didn't exhaustively check if is
possible that the bindings could
be returned uninitialized or null from native code - I don't think it is
possible, but I added the
null check, just in case.
regards
Mark
On 06/03/2017 22:16, Martin Buchholz wrote:
It would not have both the never-null property and the check for null.
I would probably just leave bindings null in the constructor and check
for null whenever reading bindings.
On Mon, Mar 6, 2017 at 2:00 PM, Mark Sheppard
<mark.shepp...@oracle.com <mailto:mark.shepp...@oracle.com>> wrote:
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/
<http://cr.openjdk.java.net/%7Emsheppar/8175325/webrev/>
for the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8175325
<https://bugs.openjdk.java.net/browse/JDK-8175325>
the scenario is that a MulticastSocket, bound to a wildcard
address, which has yet to have its NetworkInterface
set, will return a synthesized NetworkInterface for a
getNetworkInterface method call. The newly constructed
has no InterfaceAddress bindings instantiated, resulting in a NPE
when getInterfaceAddresses is invoked.
The fix initializes the bindings member variable with an empty
array, as per suggestion in the bug, and also,
for completeness, places a null check in the getInterfaceAddresses
method.
There is a side issue here, relating to the synthesis of a
NetworkInterface for a MulticastSocket
bound to a wildcard address. This is somewhat dubious semantics,
and would seem to be worthy of review
at some stage in the future.
regards
Mark
