RFR: 8213942:URLStreamHandler initialization race

[Chris Hegarty]

Sean,

> On 20 Nov 2018, at 17:55, Seán Coffey <sean.coffey at oracle.com> wrote:
> 
> A race condition recently reported by the WLS team. Access to the handlers Hashtable and the factory should be made while holding the streamHandlerLock lock.
> 
> WLS team also made efforts to create a reproducer. I've modified to jtreg format and reduced it down further for unit testing.
> 
> https://bugs.openjdk.java.net/browse/JDK-8213942
> webrev: http://cr.openjdk.java.net/~coffeys/webrev.8213942/webrev/

The issue being observed only applies to protocols where there is a
built-in handler implementation, otherwise I don't see how it can occur.
The test uses `http`, and clearly there is a built-in `http` handler.

This is all very racy, partly by design, partly not. I can see that the
changes in JDK 9 in this area altered the behaviour in such a manner
that the test which ran successfully on JDK 8, no longer runs
successfully on JDK 9.

I see you have some other comments, and I share Pavel's and Alan's
concern. I've taken a look at the JDK 8 code again [1], and maybe the
safest thing here is to try to revert back to a variant that closely
resembles that.

One thing to try is to move the `if` statement L1396 outside of the
synchronized block, and then remove the `else` on L1400. That will allow
both the handlers cache to be rechecked and the factory ( if there is
one ) to re-consulted. I believe that should resolve the issue, more
closely resemble JDK 8, and also address the comments so far ( with 
minimal change ).

-Chris.

[1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/net/URL.java