Collecting enhancement requires for Jakarta JSON-B vNext

69 views
Skip to first unread message

Andy Guibert

unread,
Sep 4, 2019, 5:50:33 PM9/4/19
to Eclipse MicroProfile
Hi all,

As many of you know, Jakarta JSON Binding (JSON-B) 1.0 is one of the technologies that MicroProfile has adopted from the JavaEE/JakartaEE platform. It is an integral technology for microservices, especially for JAX-RS services that communicate with JSON data.

I'm working on collecting up enhancements for the next version of JSON-B, and would be interested in hearing about any ideas or pain points from the MP community.

To prime the conversation a bit, here are some of the upcoming features we have planned:

Larger features
 - Customize 3rd party classes (jsonb-api #88)
 - Polymorphic [De]serialization (jsonb-api #147)
 - Map directly to/From JsonGenerator and JsonParser (jsonb-api #122)

Smaller features
 - Using @JsonbCreator with absent/optional fields (jsonb-api #121)
 - Configurable interface --> impl mappings  (jsonb-api #65)
 - Automatically register Adapters/[De]Serializers (jsonb-api #35)
 - Opt out of the “must ignore” policy (jsonb-api #56)
 - Customize date formats of different types (jsonb-api #87)

Here is a link to the full set of features being considered: https://github.com/eclipse-ee4j/jsonb-api/projects/1

If you have concrete suggestions for JSON-B, please open an issue on github here: https://github.com/eclipse-ee4j/jsonb-api

If you have less-than-concrete ideas or just some questions, we can discuss here on the mailing list and move to github issues if needed.

Thanks,
Andy Guibert

m.reza.rahman

unread,
Sep 4, 2019, 6:48:53 PM9/4/19
to microp...@googlegroups.com
This is more for JSON-P than it is for JSON-B, but has JSON schema validation been discussed?

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/082815f5-7d72-4e55-ba1f-3510130dd10b%40googlegroups.com.

Denis Frank

unread,
Sep 5, 2019, 7:52:16 AM9/5/19
to Eclipse MicroProfile
Hi,

it would be great if JSON-B could have feature to define different "views" on the DTO classes. In Jackson "@JsonView" annotation can be used for this purpose. 
With this feature you could reuse your DTOs for generation of JSON with different detail levels. For example you could have an OrderDTO that you could use to generate a JSON with minimum set of information that can be used to implement shopping cart with a view "ShoppingCart" and a JSON with all informations in case the order must be loaded to generate a print out with a view "PrintOut".  

Greetings
Denis Frank   

Werner Keil

unread,
Sep 5, 2019, 3:50:36 PM9/5/19
to Eclipse MicroProfile
I wonder, if JSON schema is mature enough already, but since "Justify" (https://json-schema.org/implementations.html) already implements it on top of JSON-P, there could be possible synergies and contributions to the actual spec or implementations, too. 
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

Johnny T

unread,
Sep 5, 2019, 4:35:45 PM9/5/19
to Eclipse MicroProfile
It would be nice, if immutable objects with builders could get serialized.
If would be nice, if basic things (like immutable objects) could be configured once and done without jsonb annotations.
It would be nice, if schema-changes (default for missing field, ignoring deleted field, plain field to object,..) could be done by providing methods (e.g. builder methods), having things like upcasters of eventdriven Systems in mind.
It would be nice, if config and jsonb could be injected or reached inside adapters and serializers.
It would be nice, if adapters and serializers could use/delegate to default behavior.
It would be nice, if configuration defaults provide most things with convention over code in mind or some templates.
It would be nice, if simple objects could be serialized using json-b, jaxb, Jackson, Java serialization only by configuration and without changing all those objects (or putting tons of annotations on them using code generators).

Andy Guibert

unread,
Sep 5, 2019, 5:53:39 PM9/5/19
to Eclipse MicroProfile
Hi Reza,

Not validation specifically, but Andy McCright has raised a similar issue for exposing a JSON Schema as JSON-B sees it:

If this issue came to fruition, I could see us adding some sort of validation to it. Perhaps:
JsonSchema schema = Jsonb.schemaForClass(Foo.class);
String incomingJosn = // ...
schema.matches(incomingJson);

If you think this issue captures what you had in mind well enough, give the issue a +1 so we can track your vote.

Thanks,
Andy
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

Andy Guibert

unread,
Sep 5, 2019, 5:56:41 PM9/5/19
to Eclipse MicroProfile
Hi Denis,

Yes Jackson Views are an interesting feature, and that's a request I heard once a while back. You can sort of achieve the equivalent to Jackson Views by using object inheritance, or a custom PropertyVisibilityStrategy, but I'd consider that a workaround for now.

Would you mind opening an issue for this? I think it would be a good item to discuss further:

Thanks,
Andy

Andy Guibert

unread,
Sep 5, 2019, 6:21:39 PM9/5/19
to Eclipse MicroProfile
Hi Johnny, quite a few requests here so I'll answer them one at a time:

> It would be nice, if immutable objects with builders could get serialized.

Serializing (POJO-->JSON) immutable objects w/ builders is already possible, since you hand JSON-B the object instance and it "reads" the fields to create a JSON.
I assume you meant to say deserialization (JSON-->POJO) here?
If yes, this is something we're look at addressing part of this in the next version of the spec here:
This will allow "all args" constructors or "all args" static builder methods to work.
If you have a static builder, writing a custom JsonbDeserializer (or JsonbAdapter) would be the best thing to do.


> If would be nice, if basic things (like immutable objects) could be configured once and done without jsonb annotations.

Configured once where? And configuration for what scope? The basic case for immutable objects works OK if you have public fields and/or getter/setter methods, along with a no-args or all-args constructor.


> It would be nice, if schema-changes (default for missing field, ignoring deleted field, plain field to object,..) could be done by providing methods (e.g. builder methods), having things like upcasters of eventdriven Systems in mind.

This is an interesting idea, can you open an issue for this one please?


> It would be nice, if config and jsonb could be injected or reached inside adapters and serializers.

This would sort of cause a circular dependency issue if JsonbConfig and Jsonb were CDI beans, as well as the adpaters/serializers. I take it the reason why you want to do this is to do a small amount of customization in your adapter/serializer and then pass off the remaining work the the same jsonb instance? If that's the case, I think this planned enhancement will solve the use case:


> It would be nice, if adapters and serializers could use/delegate to default behavior.

I think this case will be covered by the upcoming enhancement mentioned in the previous feature. This new ClassCustomization API should be much more concise for small customizations and eliminate the need for most custom [de]serializers and adapters.


> It would be nice, if configuration defaults provide most things with convention over code in mind or some templates.

I think the JsonbConfig defaults are pretty sensible. What configuration options specifically do you wish were different or find yourself always needing to change? The only one that comes to mind is prettyPrint=true/false, which currently defaults to false in order to improve performance. I can see how some users may find this annoying if they care about readability more than performance though.


> It would be nice, if simple objects could be serialized using json-b, jaxb, Jackson, Java serialization only by configuration and without changing all those objects (or putting tons of annotations on them using code generators).

A bit confused by this one. Simple objects can indeed be serialized in JSON-B without any annotations or reference to JSON-B. For example, if I have the class:

public class Dog {
  public String name;
  public long id;
  public boolean bites;
  public int age;
}

It can be serialized/deserialized as-is by doing this:
Jsonb jsonb = JsonbBuilder.create();
Dog dog = // init the object however
String json = jsonb.toJson(dog);
Dog dogAfter = jsonb.fromJson(json, Dog.class);
// 'dog' and 'dogAfter' will have identical fields

Regards,
Andy

m.reza.rahman

unread,
Sep 5, 2019, 6:49:51 PM9/5/19
to microp...@googlegroups.com
One of the issues I have been dancing around is whether I actually contribute as a Microsoft representative or as an individual. From an IP standpoint, I can do neither at this point. The reason this matters is that I am unsure how the IP flow works if I actually begin entering things into GitHub. Do you think it is OK to just enter some comments in an issue including example code or does this get us into a funny situation we should try to avoid? Hopefully I don't need to dance around IP too much longer. I hope to sort this out on my end sooner rather than later now that this really matters for Jakarta EE.

By the way, I highly appreciated your responsiveness to basically all the input you have received here. This is more of what I had hoped to see in Jakarta EE. It is certainly a refreshing change compared to what went down for Java EE 8.

Reza Rahman
Principal Program Manager
Java on Azure

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ed470b2d-4fee-41bd-a6de-266ba8e6f811%40googlegroups.com.

Andy Guibert

unread,
Sep 5, 2019, 7:08:12 PM9/5/19
to Eclipse MicroProfile
I'm not a lawyer, but I would assume simple issue comments are OK. I work for IBM, which I imagine has similar legal restrictions to Microsoft and have not had any issues being active on github issues for various projects. When I get to the point of needing to open a PR on a new project, that's when I need to involve my legal department and get approval.  Also, I know that in MP we only require contributors to sign the ECA (Eclipse Contributor Agreement) once they try to propose some code with a PR.

> Do you think it is OK to just enter some comments in an issue including example code or does this get us into a funny situation we should try to avoid?

I certainly won't complain to anyone if you do! It's up to what you feel comfortable with doing as a MS employee I guess.

Also, I believe we'll both be at Oracle Code One and can probably chat in person there if needed?

m.reza.rahman

unread,
Sep 5, 2019, 7:24:36 PM9/5/19
to microp...@googlegroups.com
OK, let us keep our fingers crossed. I'll just open a new issue with details. We can take the discussion there going forward. Either way, happy to chat at Code One. I will be at the Microsoft booth at OOW most of the time.

Reza Rahman
Principal Program Manager
Java on Azure

Please note views expressed here are my own as an individual community member and do not represent the views of my employer.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a7b1b2ae-1940-49d0-8c77-7b06acfa7bda%40googlegroups.com.

Ken Finnigan

unread,
Sep 13, 2019, 9:21:51 AM9/13/19
to MicroProfile
I asked the Quarkus community what, if any, additions they might want in JSON-B.


Ken

Ondro Mihályi

unread,
Sep 14, 2019, 2:15:15 AM9/14/19
to Eclipse MicroProfile
Hi Andy,

A while ago, I hit an issue with JSON-B and interfaces/abstract classes. JSON-B doesn't automatically add information about the actual class into JSON so that it can be deserialized on the client into the appropriate class. Jackson provides multiple ways how to do this with the @JsonTypeInfo annotation, e.g. by sending the class name as an additional JSON attribute. I didn't find a simple way how to instruct JSON-B to pass this information into JSON. The only way I found is to use a custom serializer which is too complex for such thing.

In short, JSON-B doesn't have a simple alternative to Jackson's @JsonTypeInfo annotation to support polymorphism.

Ondro


On Friday, September 13, 2019 at 6:21:51 AM UTC-7, Ken Finnigan wrote:
I asked the Quarkus community what, if any, additions they might want in JSON-B.


Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

Andy Guibert

unread,
Sep 14, 2019, 1:23:21 PM9/14/19
to Eclipse MicroProfile
Ken, thanks for reaching out to the Quarkus community. I've posted over on your mailing list and will work with people from there.

Ondro,

Yes polymorphic deserialization is something we are looking at solving in the next version of the spec. Here is a link to the spot in my JakartaOne presentation where I talked about this item:

Here is the specific github issue where we are tracking/discussing it: 

FWIW, the easiest way to do polymorphic deserialization in JSON-B 1.0 is to use a JsonbAdapter, but even that is a non-trivial amount of code which is why we are looking at simplifying going forward.

- Andy

Johnny T

unread,
Sep 21, 2019, 3:42:20 AM9/21/19
to Eclipse MicroProfile
Thank you Andy for your answer. 
I was just "brainstorming" and did not consider putting in my thoughts one at a time.
I opened an issue for the versioning idea: https://github.com/eclipse-ee4j/jsonb-api/issues/192
Reply all
Reply to author
Forward
0 new messages