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 :
Provided the same set of java.security.Provider implementations are loaded, the same SecureRandomSpi implementation is used by the returned SecureRandom implementation.
The actual implementation depends on the order of the entries Provider's Hashtable.
FREQUENCY : always