Thanks for the clarification, Anders. If you are working from Nashorn, the simplest way to enforce JS formatting is to coerce the Java number (whatever type it is) to a JS number, e.g. using unary + operator.
If you need this in Java core libs, the place to discuss this would be the core-libs-dev mailing list rather than nashorn-dev, but I think the chances to get such specialised functionality to core libs would be very slim. Hannes > Am 29.01.2018 um 15:46 schrieb Anders Rundgren > <anders.rundgren....@gmail.com>: > > On 2018-01-29 15:49, Sundararajan Athijegannathan wrote: >> Just to be clear. so.. do you want a toString (static method?) variant >> in java.lang.Double class as per this specification? > > I don't think this is a major issue because all fundamental JSON types anyway > needs be dealt with separately or through a super interface. > The existing Nashorn method (after upgrade to match ES better) moved to the > Java layer would probably be just fine. > > Anders > >> -Sundar >> On 29/01/18, 7:45 PM, Anders Rundgren wrote: >>> On 2018-01-29 14:52, Hannes Wallnöfer wrote: >>>> Hi Anders, >>>> >>>> I think I lack the context required to understand what you’re asking >>>> for. Can you explain how transmitting numbers/doubles in JSON should >>>> work and how the static method you’re asking for would enable this? >>> >>> Sure. Signatures depend on that data appears identical on both sides >>> (sender + receiver). >>> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), >>> the signature will break in an EcmaScript environment where it must be >>> 10 and nothing else. >>> JSON tools would call the proposed static method rather than building >>> their own number serializer. >>> >>> Initially I thought number serialization was a simple problem but that >>> was entirely wrong :-) >>> Fortunately the ECMA folks have the expertize needed and their >>> solution is already supported in billions of devices. >>> Nashorn almost cuts it but only for JavaScript, not Java. >>> >>>> Also, is there a document somewhere describing the IETF >>>> standardization work you’re talking about? >>> >>> You will have to wait to next week (when it becomes public), but in >>> the meantime you can take a look at the core "input specifications": >>> https://cyberphone.github.io/doc/security/jose-jcs.html >>> https://cyberphone.github.io/doc/security/jose-jef.html >>> >>> Thanx, >>> Anders >>> >>>> >>>> Thanks, >>>> Hannes >>>> >>>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren >>>>> <anders.rundgren....@gmail.com>: >>>>> >>>>> The JSON "clear text" signature initiative seems to (finally) be >>>>> headed for IETF standardization. The plan is having a BOF session >>>>> at the next IETF in London. >>>>> >>>>> This scheme builds on EcmaScript JSON processing rules for data >>>>> normalization which only rely on JSON.parse() and JSON.stringify(). >>>>> >>>>> A thorny issue for implementers is though serializing the JSON >>>>> "Number" type. >>>>> >>>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely >>>>> compatible...) solution is currently available in "Nashorn": >>>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java >>>>> >>>>> >>>>> It would be great if such support could for example be included as a >>>>> static method in java.lang.Double, making Java and >>>>> EcmaScript/JavaScript 100% interoperable with respect to this >>>>> feature, the rest is actually close to trivial. >>>>> >>>>> thanx, >>>>> Anders >>>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705 >>>>> >>>> >>> >
