thing is that the spec intent was to enable to not respect the type of the binding (ie if you have an object you can serialize as a list or primitive and vice versa) but also the opposite which was the case the test was validating....but anyway all that is totally not spec-ed properly so long story short (de)serializer are not usable in a portable code so only point for me: is the new behavior good for everyone or does the change bothers more than it helps.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 27 févr. 2026 à 21:00, Mark Struberg <[email protected]> a écrit : > Well, Imo the old test was also off, so it did indeed create broken JSON. > > See > > https://github.com/apache/johnzon/commit/c94db5ee3cd0864fb749e0445b264aa662aaad4b > > - "{\"detailName\":{\"name\":\"Another Test > String\",\"detail\":true},\"name\":{\"name\":\"Test String\"}}", > + "{\"name\":{\"detailName\":{\"name\":\"Another Test > String\",\"detail\":true},\"name\":\"Test String\"}}", > > The problem with the original code is with the part > \"name\":{\"name\":\"Test String\"} > This is something which should never have been affected by any Serializer. > Even if we interpret the spec as it was before in Johnzon - the > @JsonbTypeSerializer getting applied for the whole String name = "Test > String"; And this is "name":"Test String"; > The old code introduced a 2nd layer for that attribute (a superfluous > "name":{} ) which was clearly wrong. > I tried to fix this flaw in the old code but gave up. The information gets > lost in the TypeSerializer as it has no knowledge about our MapperImpl. And > then the 'lazy' mechanism of the DynamicMapperImpl triggers at the wrong > attribute. > That's why I moved the 'dynamic' part to the DeferedStartJsonGenerator. > > LieGrue, > strub > > > > Am 27.02.2026 um 20:36 schrieb Romain Manni-Bucau <[email protected]>: > > This is true as well as the fact the new implementation is not in the spec > and is not supported by the RI so doesn't help much to pick one IMHO. > I understand it solves your case as the old one was solving one as well - > main reason I don't +1 cause now you are no more able to make it work. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old Blog <http://rmannibucau.wordpress.com/> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > Javaccino founder (Java/.NET service - contact via linkedin) > > > Le ven. 27 févr. 2026 à 20:21, Mark Struberg <[email protected]> a écrit : > >> >> >> Am 27.02.2026 um 17:32 schrieb Romain Manni-Bucau <[email protected] >> >: >> >> 3. it might go against the JSON-B spec spirit even if I never liked this >> part of (de)serializers and found it ackward to not be reusable >> >> >> I never found anything in the spec which supports our old implementation. >> There are even samples from other vendors who imo work in favour of our new >> implementation. You are of course right that this is not fully backward >> compatible. Otoh I've not seen many JsonbTypeSerializers on fields. There >> is definitely nothing in the JSON-B spec which supports our old >> implementation. Nor is there anything such in the JavaDocs nor in the TCK. >> >> Just the fact that they used to work different when you annotate it on >> the field vs annotate it on the type or configure it is something I really >> don't like. >> >> LieGrue, >> strub >> > >
