Support of Scala.js 1.10.0

[catap]

Scala.js released 1.10.0 which contains broking changes inside java.lang.UUID which forces to use java.security.SecureRandom: https://www.scala-js.org/news/2022/04/04/announcing-scalajs-1.10.0/

TestSortingReporter is using UUID.randomUUID which can't be used in sjs since this release, it fails on compiling like:

[error] Referring to non-existent class java.security.SecureRandom
[error]   called from private java.util.UUID$.csprng$lzycompute()java.util.Random
[error]   called from private java.util.UUID$.csprng()java.util.Random
[error]   called from java.util.UUID$.randomUUID()java.util.UUID
[error]   called from static java.util.UUID.randomUUID()java.util.UUID
[error]   called from org.scalatest.tools.TestSortingReporter.distributingTest(java.lang.String)void
[error]   called from org.scalatest.AsyncSuperEngine.runTestImpl(org.scalatest.Suite,java.lang.String,org.scalatest.Args,boolean,boolean,scala.Function2,scala.concurrent.ExecutionContext)org.scalatest.Status
[error]   called from static org.scalatest.wordspec.AsyncWordSpecLike$class.runTest(org.scalatest.wordspec.AsyncWordSpecLike,java.lang.String,org.scalatest.Args)org.scalatest.Status
[error]   called from
...

I not sure how this should be fixed on the right way:

• by adding dependency from fake SecureRandom;
• moving away from UUID.

Impact? Huge. AsyncWordSpec and similar things are affected.

@cheeseng

[gzm0]

Oh dear. /cc @sjrd for visibility.

by adding dependency from fake SecureRandom;

Please do not do that. It'll spread the fake SecureRandom everywhere (even if it is just in the test config).

moving away from UUID.

You can write your own implementation of UUID.randomUUID (using a java.util.Random). The rest of UUID is unaffected. (please make sure you can actually live with predictable UUIDs, but at least superficially, it seems in a testing framework to identify test runs, that should be fine).

[gzm0]

Implementation of randomUUID in Scala.js:

https://github.com/scala-js/scala-js/blob/e41949e96b91fb4d48e65e3cd9a15b57e518d673/javalib/src/main/scala/java/util/UUID.scala#L143-L160

As a stop gap measure, you could just copy this and use val rng: Random = new java.util.Random() instead of csprng.

[catap]

@gzm0 to be honest I really think that this changes in SJS a kind of disaster.

[sjrd]

by adding dependency from fake SecureRandom;

Please do not do that. It'll spread the fake SecureRandom everywhere (even if it is just in the test config).

I cannot emphasize this enough. Don't depend on scalajs-fake-insecure-java-securerandom in a library, ever.

You can write your own implementation of UUID.randomUUID (using a java.util.Random). The rest of UUID is unaffected. (please make sure you can actually live with predictable UUIDs, but at least superficially, it seems in a testing framework to identify test runs, that should be fine).

This is probably the way to go.

Another possibility is to indeed move away from UUID in the specific case of TestSortingReporter. The UUID only seems to serve as an in-memory identifier, privately within TestSortingReporter. An object identity would achieve the same result more efficiently and more reliably.

[sjrd]

@gzm0 to be honest I really think that this changes in SJS a kind of disaster.

Yes, it is. So is leaving a gaping security hole in the middle of a codebase as widely depended on as Scala.js.

[sjrd]

Here is a proposed fix: #2117