On 02/05/2019 10:33, Andre Naujoks wrote:
:
I just wanted to notify you, that the whole issue with binding to a
multicast address is not Linux specific.
Understood as it's always been platform specific as to whether you could
bind to a multicast address. This is one of the reason why we've had
On 2019-05-02 15:20, Seán Coffey wrote:
Hi Claes,
Yes - looks like a fine suggestion.
http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/
Looks good to me.. ;-)
/Claes
Hi Claes,
Yes - looks like a fine suggestion.
http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/
regards,
Sean.
On 02/05/2019 13:15, Claes Redestad wrote:
Hi Seán,
wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both
Hi Seán,
wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both cases if the protocol is
non-overrideable?
I.e., something like this:
diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
---
with webrev: https://cr.openjdk.java.net/~coffeys/webrev.8217364.02/webrev/
regards,
Sean.
On 02/05/2019 11:00, Seán Coffey wrote:
Been thinking a bit more about this one.
Given that only initialization code will traverse through the "if
(!isOverrideable(protocol))" check, I think we can add
Been thinking a bit more about this one.
Given that only initialization code will traverse through the "if
(!isOverrideable(protocol))" check, I think we can add synchronization
to eliminate any timing scenarios where the handlers Hashtable gets
populated via another thread after we make the
Am 02.05.19 um 10:25 schrieb Alan Bateman:
> On 02/05/2019 08:44, Andre Naujoks wrote:
>> Hello all.
>>
>> I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
>> 12. With a new bug JDK-8215294 taking over the issue.
> Yes, it caused problems so had to be reverted. In addition
Hi Arthur,
On the surface, this looks good.
However I have a concern about two things:
1. IPSupport needs to read system properties, attempts
to bind sockets etc... I wonder how that might interact
with tests that use a security manager, as some of these
operations may throw a
On 02/05/2019 08:44, Andre Naujoks wrote:
Hello all.
I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
12. With a new bug JDK-8215294 taking over the issue.
Yes, it caused problems so had to be reverted. In addition to
JDK-8215294 there is also JDK-8216417 which we expect
Hello all.
I just noticed, that the fix from Bug JDK-8210493 was reverted for Java
12. With a new bug JDK-8215294 taking over the issue.
Just to let you know, the issue is not linux specific (as the new bug
states). A test on a windows machine resulted in the same behavior.
Andre
### win10,
On 01/05/2019 23:53, Arthur Eubanks wrote:
Webrev: http://cr.openjdk.java.net/~aeubanks/8223214/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8223214
NetworkInterface.getByInetAddress denies knowledge of addresses that you
don't have a permission to connect to so I think this will
11 matches
Mail list logo
