Andrew Guibert

Just noticing this issue now, at first glance I'm thinking it is a Yasson issue. (I work on Quarkus and Yasson so it would go to me either way though...

hi @moghaddam thanks for raising this issue. This seems like a reasonable request. Currently the spec says the following on this topic: > The deserialization operation of a property with...

Yes, I agree the current behavior could be improved. I think we should change the spec so that null values for primitives are ignored by JSON-B (i.e. don't set the...

I think the overall usecase is reasonable to support. We should document that `originalJsonb.getConfig()` returns a COPY of the `JsonbConfig` though, so that it's clear the configuration for `originalJsonb` won't...

I just noticed this fragment in the end of section 4.2 of the 1.0 spec: > ## 4.2 Customizing Property Order > > ... > The order is applied to...

It seems that the `@JsonbPropertyOrder.value()` attribute has its own javadoc which I had been missing, which explicitly defines behavior: ```java /** * Order in which properties are serialized. Names must...

I like the idea of supporting the builder pattern in JSON-B, since it's a common alternative to a public all-args constructor when creating immutable objects.

both documents point to the same allowed grammar. Am I missing something?

@Simulant87 currently it is true that BigDecimal is output as String and numbers are output as non-Strings, but this difference in type based on number value also causes issues. We...

hi @mkarg thanks for the PR! I agree it would be good to update the spec doc at the same time as the javadoc so we don't lose track and...