Re: [Json] JSL: Clarifying purpose, and renaming it to JDDF

[Ulysse Carion <[e-mail]>]

> And even these additions don't make Java's standard sorting or printing work for uint8. Generated code cannot merely using byte for uint8; it also needs to add code so a byte-as-uint8 is serialized differently to a normal byte-as-int8.

It's true that the standard sorting and printing stuff doesn't work
as-is. It's untrue that one cannot merely use byte for uint8, or int
for uint32. gRPC does this. It's quite common to use []byte in a
context where the byte is known, beyond the type system, to represent
unsigned numbers.

Serializing an int back to JSON is a stronger point. But code
generation can deal with this by overriding the relevant
fromJSON/toJSON or equivalent. Both gson and Jackson have such
functionality. This is unpleasant, but handled entirely by the code
generator. But from the user's perspective they have a POJO they can
immediately use, and which behaves correctly with respect to SerDe.
That's what matters most for a code generating tool, in my view.

Having to write special serialization logic happens already for the
discriminator form, and for many languages the timestamp data type.
But the important thing is that the codegen'd code can contain this
nastiness, and automate away having to write such code.

> If I saw uint8 in JDDF, I'd almost certainly want control over whether it became a byte or short in my Java code, depending on the situation.

This is a very sensible position. Sounds like jddf-codegen ought to
support such an option, and equivalents for uint16 and uint32.

> But if the spec is too minimal it isn't worthwhile.

Yes, but as it is I don't think the spec meets this "too minimal" threshold.

On Sun, Sep 1, 2019 at 6:45 PM Manger, James
<[e-mail]> wrote:
>
> >> JDDF offers "type":"uint8" but very common languages, such as Java, don't have an unsigned 8-bit type. So code generation might use a short (16-bit signed integer) to handle the [0, 255] range. That seems to put the code in a very similar situation to using a long when the JDDF says "int54". In both cases the native type can hold values that the schema doesn't allow, requiring extra parse/stringify functions if you really want to enforce the schema's rules.
>
> >This isn't quite right. Yes -- Java only has "byte", but by convention you can store both signed and unsigned 8-bit numbers in these bytes.
> >Protobufs does this:
>
> That is certainly 1 reasonable choice for a code generator.
>
> >Furthermore, the Java standard library has methods that explicitly let you do the conversion of a Java byte-as-uint8 into a Java int or long:
> >
> >https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedInt-byte-
> >https://docs.oracle.com/javase/8/docs/api/java/lang/Byte.html#toUnsignedLong-byte-
> >
> >If bytes-as-uint8 weren't conventional, then why does java.lang.Byte have methods that enable such a style?
>
> Did you notice the "Since 1.8" annotation on those methods? This support for byte-as-uint8 was only added in Java 8.
> And even these additions don't make Java's standard sorting or printing work for uint8. Generated code cannot merely using byte for uint8; it also needs to add code so a byte-as-uint8 is serialized differently to a normal byte-as-int8.
>
> Short-as-uint8 has different properties: sorting & serializing works as "normal", but it takes twice as much memory.
>
> If I saw uint8 in JDDF, I'd almost certainly want control over whether it became a byte or short in my Java code, depending on the situation.
>
>
> >> * "type": "intString" ...
> >> * "type": "uintB64u" ...
> >> * "type": "bytesB64" ...
> >> * "type": "bytesB64u" ...
>
> > I think I'm opposed to this suggestion. Adding support for arbitrary binary data is going to be challenging. I think I prefer that we just stick to {"type":"string"}, and then folks can write their own extensions to JDDF to achieve their specific needs. After awhile, the community may perhaps converge on common extensions, or patterns may arise and we can update the JDDF spec.
> >
> >Anything we add to the spec now would have to be supported by all implementations. So I'd prefer we give out a minimal spec to the world, and see where the real world takes it. If we try to solve all problems right away, we may make it too hard for implementations to crop up, ultimately solving no problems for anyone.
>
> But if the spec is too minimal it isn't worthwhile.
>
> --
> James Manger