Make all numeric coercions explicit.

Optimistically, this is preparation for a day when we don't
let numeric types drift with the winds. Even without the optimism
it's a good idea. It flushed out an undocumented change in
the math package object relative to the methods being forwarded (a
type is widened from what is returned in java) so I documented
the intentionality of it.

Managing type coercions manually is a bit tedious, no doubt,
but it's not tedious enough to warrant abandoning type safety
just because java did it.

Author: paulp

src/library/scala/util/parsing/json/Parser.scala

@@ -83,7 +83,7 @@ object JSONFormat {
        * Per RFC4627, section 2.5, we're not technically required to
        * encode the C1 codes, but we do to be safe.
        */
-      case c if ((c >= '\u0000' && c <= '\u001f') || (c >= '\u007f' && c <= '\u009f')) => "\\u%04x".format(c: Int)
+      case c if ((c >= '\u0000' && c <= '\u001f') || (c >= '\u007f' && c <= '\u009f')) => "\\u%04x".format(c.toInt)
       case c => c
     }.mkString
 }