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 >
