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
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
wrote:
> Hi,
>please oblige and review
Hi,
please oblige and review the change
http://cr.openjdk.java.net/~msheppar/8175325/webrev/
for the issue raised in
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
On 06/03/2017, 11:12, Chris Hegarty wrote:
On 06/03/17 11:00, Daniel Fuchs wrote:
On 01/03/17 15:40, Michael McMahon wrote:
Hi
Could I get the following JDK 9 change reviewed, please?
In addition to fixing the spec problem around HTTP version,
it fixes an implementation issue with version
On 06/03/17 11:00, Daniel Fuchs wrote:
On 01/03/17 15:40, Michael McMahon wrote:
Hi
Could I get the following JDK 9 change reviewed, please?
In addition to fixing the spec problem around HTTP version,
it fixes an implementation issue with version also, where the per-request
version (if set)
On 01/03/17 15:40, Michael McMahon wrote:
Hi
Could I get the following JDK 9 change reviewed, please?
In addition to fixing the spec problem around HTTP version,
it fixes an implementation issue with version also, where the per-request
version (if set) was not being picked up.