I'm -+0 mainly cause I don't depend on johnzon 2 (still v1 or forks) cause 1. This is not specified and actually more likely to not be supported - yasson just fails 2. dropping DynamicMappingGenerator will break applications for sure since tests got broken by these changes (not saying it is stupid or not justified but tests were written in a way it is used by some apps/frameworks in geronimo ecosystem) 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
longer term we might want to enable to forbid these undefined cases somehow with a jsonbconfig toggle to encourage portability and try ot get something cleaner at jakarta IMHO - but this will be tricky since it must break the spec to be usable :( 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 à 15:50, Mark Struberg via dev <[email protected]> a écrit : > Hi! > > I recently fixed a few bugs in Johnzon and also had to slightly change the > behaviour for an edge case. > > Consider having the following class > > @JsonbTypeSerializer(MySerializer.class) > @JsonbTypeDeserializer(MyDeserializer.class) > public class MyPojo1 { > private String a; > private int b; > ... > } > > and you use that in a > > public class MyPojo2 { > private int x; > private MyPojo1 val; > ... > } > > In this case the Json for MyPojo2 always looks like > > { > "x":4711; > "val":WHATEVER > } > > Where WHATEVER is whatever the MySerializer writes. That might be a > primitive or a complex JsonValue. > The exact same output is generated if you don't have the > @JsonbTypeSerializer annotation on MyPojo1 but give the MySerializer.class > as JsonbConfig#withSerializer. > > BUT if you do move the annotation from the MyPojo1 class to the field in > MyPojo2, then our old code did behave different. In this case we did give > the JsonbSerializer control over the WHOLE attribute. That means you also > had to explicitly write the attribute name as well! Means instead of > > { > "x":4711; > "val":WHATEVER > } > > you did get > > { > "x":4711; > WHATEVER > } > > That WHATEVER in this case could also be dozen different attribute > embedded directly in the json structure of MyPojo2. I didn't get this at > first and there is also no unit test nor TCK test for it. Actually this > whole part is badly underspecified it seems. I just fixed the > "JsonGenerationException: write(param) is only valid in arrays" I reported > in JOHNZON-421. > > I think the new behaviour is arguably more consistent and is also what is > indicated by blog posts by other big EE vendors. Still it is a small change > which might justify or even require to update our minor version. Means I'd > prefer going to up to Johnzon 2.1.0 and 1.3.0. > > Wdyt? > > txs and LieGrue, > strub > > >
