tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Johnzon - bugs or features?
Date Thu, 09 Jun 2016 07:00:12 GMT
Very interesting feedback

Global side note: this should be done on johnzon list

Then few comments inline

Romain Manni-Bucau
@rmannibucau <> |  Blog
<> | Old Wordpress Blog
<> | Github <> |
LinkedIn <> | Tomitriber
<> | JavaEE Factory

2016-06-09 7:19 GMT+02:00 tam <>:

> @sgjava: Thanks, I'll have a try. That supports my suspicion that that
> Johnzon thing is still immature and the 0.x-incubating numbering scheme
> might be taken seriously.
Well nested objects and generics support was let's call it "mid-supported"
in last release. This is a model discussion which needs code examples and
report (on johnzon list once again) but originally (when I created the
codebase) it was just not supported at all cause I wanted to encourage
simple models. With user feedback and other committers we started to
support it but on this area there is a real compromise between code
complexity (until now johnzon code is understandable by any java dev) vs
feature support (generics can go super far). 0.9.3 already had basic
support but 0.9.4 support was enhanced to match "not flat" models.

> @Romain: Spontaneously, I was in favor of providing some documentation
> myself. But after another frustrating week with TomEE 7 and that Johnzon
> thing, the old textbook wisdom came to my mind: Documenting an artefact can
> only be done by its developers. As long as documentation is lacking, a user
> like me can only guess about the properties of the artefact and therefore
> not give any valid advice to others.
Well this is one way to see things, the other is to see tests as
documentations and as soon as you are a java dev you can then write the
doc, committer or not. For johnzon that's typically the case and if you
want to write something about generics you can start by reading this test
for instance.

Also don't forget when I say you are a good candidate to write the missing
doc it doesn't mean you have to do it alone. We would be very happy to
support and help you if anything is unclear or you don't find/understand
entry points.

> Examples: I have one POJO that gets properly serialized without any @Xml...
> annotations. It has private fields and public getters and setters. Other
> POJOs, also having private fields and public getters and setters, won't get
> serialized without any annotations. The "documentation" given in
> shows a few lines creating a mapper for
> MySuperObject, followed by an explanation that now objects of MyModel will
> be serialized to JSON. What does MySuperObject have to do with MyModel? No
> one from the outside can shed light into this mess.
Without more info hard to diagnostic it. Only case I can think about is it
doesn't respect POJO standard cause of the visibility.

> There are three lines on JSON-B. The first of them says "not fully
> compliant". The third says "It fully reuses the JSON-B as API". Why
> "reuses"? Does it implement the API of JSON-B? If it implements it fully,
> why is it called "not fully compliant"? How should an outsider document
> where it is compliant and where not?
This means we are not able - organizationnally - to pass jsonb TCK from
Oracle but if you use johnzon as a JSONB API we - for now, will likely be
enhanced depending the user feedback - ignore johnzon mapper API.

> I'm also wary of the @JohnzonIgnore, @JohnzonConverter, and
> @JohnzonProperty
> annotations. Lots of efforts are made in the JEE world to standardize
> interfaces and make our code independent of the implementation of an
> interface. Should I actually clutter my code with library specific
> annotations?
Well, yes and no. JavaEE 7 doesn't have any standard for JSON mapping. The
only one coming will be JSON-B in JavaEE 8 so until it gets out you will
have to use vendor annotations or rely on the defaults.

If you don't want to "clutter your code" what would you use then?

> Bottom line: It is nebulous which JEE standards that Johnzon thing
> implements to what degree. Until this is resolved, it should not be
> included
> in a (non-experimental) JEE container.
This part is very simple: today and for tomee Johnzon only implements the
only JSON standard: JSON-P 1.0 (same note as JSON-B cause of the legal
thing with Oracle) which is strictly speaking not something you have to
know really as a TomEE user.

Then you kind of need to know it for JAX-RS POJO mapping cause you always
need to customize few properties but keep in mind there is nothing in
JavaEE about that so not sure there is an alternative.

> --
> View this message in context:
> Sent from the TomEE Users mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message