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, o
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
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 SecurityE
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 to
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 f
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
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
--- a/src/java.base/share/classes/ja
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 cases
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
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 a
10 matches
Mail list logo
