To me it seems that Johnson isn’t really well maintained any longer (see https://issues.apache.org/jira/browse/JOHNZON-389 and https://issues.apache.org/jira/browse/JOHNZON-388) and isn’t adopting new spec versions. So we should definitely consider moving to https://github.com/eclipse-ee4j/parsson which supports the latest specs. Haven’t tried it out myself, though.
Konrad > On 19. Apr 2023, at 15:58, Carsten Ziegeler <cziege...@apache.org> wrote: > > If we can go without maintaining our own wrapper, thats probably the better > option. > > I think to remember that I ran into issues when using the glassfish > implementation, but I can't really remember what it was. I ended up with > using some Eclipse implementation which then worked fine. > I know, the answer is not really that helpful. But at least there are > different options out there. > > Regards > Carsten > > On 19.04.2023 15:46, Robert Munteanu wrote: >> On Fri, 2022-12-09 at 09:49 +0100, Carsten Ziegeler wrote: >> (snip) >>> Which then opens the question which bundle we use at runtime for >>> jakarta.json? OOTB the johnzon implementation is too heavy as it has >>> too >>> many dependencies. So we could do the same as for the javax version >>> and >>> provide a commons.johnzon.jakarta module? >> Looks like the question is still open. Eric noted at [1] that the pax- >> exam tests use org.glassfish:jakarta.json:2.0.1 . Not sure if that is a >> good option for us. >> IIUC we would have the following options >> 1. The Glassfish implementation >> 2. The Johnzon implementation >> 3. Our own wrapper for Johnzon >> As I wasn't involved in the Johnzon migration I don't have an idea >> about what it takes to create a similar module for the Jakarta impl. >> But maybe listing the options gets the ball rolling :-) >> Thanks, >> Robert >> [1]: >> https://github.com/apache/sling-org-apache-sling-starter/pull/105#issuecomment-1513868085 > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org
