users@jsonb-spec.java.net

[jsonb-spec users] [jsr367-experts] Third party objects

From: Dmitry Kornilov <dmitry.kornilov_at_oracle.com>
Date: Mon, 09 Nov 2015 19:11:36 +0100

Hi Experts,

We are preparing a second draft of JSON-B spec. There are a few topics
we still need to discuss. I'll create a thread for each topic in the
next few weeks.

Today lets start with third party objects.

*Use case:*

We have an extenal jar with classes we need to process. We cannot add
any annotations to these classes. Default configuration doesn't process
it the desired way.

*Options are:*

*1. Jackson like MixIn annotations*

For each third party class we want to customize an internal
class/interface has to be created. This internal class has @Jsonb
annotations defined the way how it should be in a third party class.

More details:
http://wiki.fasterxml.com/JacksonMixInAnnotations

It covers most of the use cases and simple enough. The disadvantage I
see is that configuration cannot be changed at runtime because
conversion logic is defined in mix-in classes.



*2. MOXy like external metadata format*

All customizations are defined in external json document. This document
has predefined format. This document is processed during JsonbConfig
creation. Something similar to this:

JsonbConfig config = new JsonbConfig()
     .withMetadata(fileInputStream);


More details:
https://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML

I see it more complicated than mix-ins approach. The advantage is that
customizations can be created at runtime.


*3. Provide customization API (runtime annotations)*

Define an API that allows adding customizations at runtime.

Something similar to this:

JsonbCustomizer customizer = new JsonbCustomizer();
customizer.addJsonbNullableOnClass("package.ClassName", true);

customizer.addJsonbPropertyOnField("package.ClassName", "fieldName",
"value");
customizer.addJsonbPropertyOnMethod("package.ClassName", "methodName",
"value");

JsonbConfig config = new JsonbConfig()
     .withCustomizer(customizer);

I see it simple enough. Configuration can be created at runtime.
Implementations can use this API to process external metadata files
(like the MOXy one above).


*4. Leave it as it is (not really an option) *

We already have adapters. The disadvantage is that it can be not
flexible enough in cases where the same type has to be processed
differently in one configuration. It also lacks runtime configuration.


Lets discuss the options. Feel free to suggest more options.

Thanks,
Dmitry Kornilov