NumberFormatException when deserializing a 128-bit integer

Using "com.lihaoyi" %% "ujson" % "0.6.6"

val json = ujson.read("{'foo': 28291041994989161181883157038606177750}")

yields:

28291041994989161181883157038606177750
java.lang.NumberFormatException: 28291041994989161181883157038606177750
	at ujson.util.Util$.parseLong(Util.scala:57)
	at ujson.util.Util$.parseIntegralNum(Util.scala:23)
	at ujson.Js$.visitNum(Js.scala:181)
	at ujson.Js$.visitNum(Js.scala:77)
	at ujson.Parser.parseNum(Parser.scala:171)
	at ujson.Parser.rparse(Parser.scala:404)
	at ujson.Parser.parse(Parser.scala:330)
	at ujson.Parser.parse(Parser.scala:325)
	at ujson.SyncParser.parse(SyncParser.scala:23)
	at ujson.StringParser$.transform(StringParser.scala:28)
	at ujson.StringParser$.transform(StringParser.scala:27)
	at ujson.Transformable$fromTransformer.transform(Transformable.scala:13)
	at ujson.package$.transform(package.scala:2)
	at ujson.package$.read(package.scala:4)

[lihaoyi]

Note that unlike other JSON libraries, ujson.Value isn’t blessed in any way, so if you use a uJson with a different AST you need not worry about ujson.Value tradeoffs at all. In fact, internally uPickle defines its own IndexedValue AST for cases where we need the source indices and non-lossy temporary storage of the incoming JSON, and in most cases does not use an AST at all. So you don’t need to feel bad about defining your own AST for your own use case

[lihaoyi]

The uJson AST is designed to mimic the Javascript AST, which takes only numbers. If you want something else, use a different AST (or don’t use an AST, like uPickle)