Its Java so its made in usual Java way which involves definition of specification (https://jcp.org/en/jsr/detail?id=353) which tries to define common ground for all JSON processors... so if you stick with it in theory you could get multiple libs on it. In practice I don't think gson took the JSR353 idea. Another way to map XML is XStream which is a bit ancient but I think a bit easier to customize than Jackson.
Anyhow, whenever tool we take we'll be able to adjust. I wouldn't worry much of JSR353. One additional point - not sure if you spotted it but if you use IntelliJ and have a failure in driver suite test then double click on test will bring you to step which failed. There are some left overs to make it navigate to failed assertion: https://github.com/junit-team/junit5/issues/2504 Cheers, Łukasz On 21.04.2021 11:04, Sebastian Rühl wrote: > Small correction: not having native json support in java (is this 2021? :D) > in might be best to still use Jackson, but in a more native way where we > don’t work with annotations for the generated classes > > Sebastian > >> Am 21.04.2021 um 10:36 schrieb Sebastian Rühl >> <[email protected]>: >> >> Talking about Jackson, this can be soon be replaced with our native >> generated implementation. >> In Golang xml/json is already ported, in java only xml for now. >> When I’m done with that we have full control over the serialization which >> then is language agnostic and dictated by what is defined in mspec. >> (e.g. if mspec defines that the element is byte[] or byte then it will be >> generated as such (hex) across every language. For debugging purposes you >> can look at my box rendering which contains every representation [hex, >> natural, possible string on hex dump]. At the moment I haven’t ported it to >> java yet) >> >> Sebastian >> >>> Am 21.04.2021 um 10:27 schrieb Łukasz Dywicki <[email protected]>: >>> >>> Looking at very core of the issue with byte type representation (at >>> least in XML suits) I believe it was affected by mapping to/from Java. >>> Jackson has its own ways handling such payloads. >>> We really should map suites according to mspec and keep values in tests >>> according to their "canonical" representation. Without pinning it to any >>> particular language. >>> As far I remember we currently map byte[] payloads to hex strings, but >>> sometimes such representation is helpful also for digits. Earlier we had >>> base64 for byte arrays which did make it pretty hard to debug tests. If >>> we could map single bytes to hex that also would be great cause turning >>> it into digit by Jackson is not very helpful. >>> >>> Best, >>> Łukasz >> >
