I briefly thought about that. It's definitely 2.x material: it's a run-time breaking change of something that's definitely working as intended. We have tests for that behavior. (I thought it was listed in https://www.scala-js.org/doc/semantics.html, but apparently not. I'll need to add that.)

I don't think it breaks the spirit of "if it links, it works". To get a null, you need to manipulate JS-specific things. The JavaDoc cannot specify that behavior, so we get to specify it ourselves. Another perspective: there is no Scala/JVM code that, when compiled and linked with Scala.js, will give you null.

But there's no denying that there can be some undesirable consequences, like this particular issue. We could revisit.

I don't think it breaks the spirit of "if it links, it works". To get a null, you need to manipulate JS-specific things. The JavaDoc cannot specify that behavior, so we get to specify it ourselves. Another perspective: there is no Scala/JVM code that, when compiled and linked with Scala.js, will give you null.

I'm not sure I fully agree with this TBH. I think mostly because "manipulating JS-specific things" is a global property: when targeting Scala.js, you have to assume JS specific things are manipulated. As a result, breaking a base JVM assumption (getClass returns non-null) significantly weakens the cross-compilation promise (FWIW: I think this issue illustrates this very nicely).

In any case, I agree the discussion is somewhat moot for the current compatibility line. I'll just file the 2.x issue.