A DESCRIPTION OF THE PROBLEM :
Prior to the changes for https://bugs.java.com/bugdatabase/view_bug.do?bug_id=7092821 java.security.Provider retained the order in which services where added. When querying the services using java.security.Provider#getServices the iteration order of the set matched the insertion order.
Since http://hg.openjdk.java.net/jdk/jdk12/rev/9af672cab7cb this is no longer the case.

The iteration order of the Set returned by java.security.Provider#getServices was never specified to begin with so one could argue that this isn't a regression, but it does have a real impact on other JDK classes. In particular, java.security.SecureRandom#getPrngAlgorithm uses the first SecureRandom implementation it encounters from the Set returned by getServices. The consequence is that the algorithm you actually get when using java.security.SecureRandom#SecureRandom() is very poorly defined and will often differ when running code on Java 8 vs Java 12.

REGRESSION : Last worked in version 8u212

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Invoke `new java.security.SecureRandom#SecureRandom()` on Java 8 and Java 12

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Provided the same set of java.security.Provider implementations are loaded, the same SecureRandomSpi implementation is used by the returned SecureRandom implementation.
ACTUAL -
The actual implementation depends on the order of the entries Provider's Hashtable.

FREQUENCY : always