Hi Paul,
JPA @Basic and JSONB @JsonbValue are not the same.
@Basic is about marking a field as persistent and using defaults for mapping.
@JsonbValue is about using annotated field mapping instead of the whole class mapping. It’s also called a simple value customization.
This is a description which was removed from the spec:
Using javax.json.bind.annotation.JsonbValue annotation, a class can be mapped to a simple value. Class can
contain at most one mapped property or field that is annotated with javax.json.bind.annotation.JsonbValue,
otherwise JsonbException MUST be thrown. [JSB-4.5-1]
Annotation javax.json.bind.annotation.JsonbValue indicates that result of the annotated non-void method
or field or constructor parameter will be used as the single value to representing the instance. In case of
non-void method annotated with JsonbValue annotation, JsonbException MUST be thrown. [JSB-4.5-2]
Example:
// Only one JsonbValue annotation is allowed per class
public class Language {
public int id = 1;
@JsonbValue
public String code = “en";
public String name = "English";
}
is serialized as just “en”
and
public class Customer {
public int id;
public Language lang;
public String name;
}
is serialized as
{
"id": 1,
"lang": ”en”,
“name": ”Jason”
}
This is the same as making an adapter like
class LangAdapter implements JsonbAdapter<Language, String> {
public String toJson(Language lang) {
return lang.code;
}
public Language fromJson(String str) {
Language lang = new Language();
lang.code = str;
return lang;
}
}
And it’s not connected to @JsonbNillable at all.
Thanks,
Dmitry
> On 29 Jan 2016, at 18:55, Paul Benedict <pbenedict_at_apache.org> wrote:
>
> If I may offer a suggestion, I think @JsonbValue should return and @JsonbNillable removed.
>
> My reasoning is to make is aligned with the precedent of JPA where the JPA @Basic annotation is implied for all applicable fields (property/field). If you must do some customization, you have the option of explicitly specifying @Basic, for example, like @Basic(optional=true).
>
> I believe @JsonbValue is the equivalent of JPA @Basic and thus it should be (1) implied and (2) given attribute nillable=true.
>
> Lastly, my suggestion is also harmonious with JAXB's @XmlElement which is also (1) implied and (2) has a nillable=true.
>
> Cheers,
> Paul
>
> On Fri, Jan 29, 2016 at 11:48 AM, Romain Manni-Bucau <rmannibucau_at_tomitribe.com <mailto:rmannibucau_at_tomitribe.com>> wrote:
> Hi Dmitry;
>
> comments inline
>
> 2016-01-29 18:29 GMT+01:00 <dmitry.kornilov_at_oracle.com <mailto:dmitry.kornilov_at_oracle.com>>:
> Hi,
>
> I just pushed a spec update. Please review it and make your comments.
>
> Change list:
>
> 1. Changed enum processing. Method name() is used for serialization
> instead of toSting().
>
>
> +1
>
>
> 2. Changed serialization rules of object properties with Optional type
> and null value.
>
> Original:
> "Empty optional instances serialized as object instance properties are
> ignored during serialization."
>
> Changed to:
> "Empty optional instances serialized as object instance properties are
> treated as null."
>
> The main purpose of this change is to make Optional fields processing
> consistent with Optional array elements and properly behaviour in case
> of @JsonbNillable(value=false).
>
> Roman Grigoriadi is preparing a detailed description of this topic at
> the moment with samples etc. It will be posted in a few days for
> discussion.
>
>
> Sounds consistent.
>
>
> 3. @JsonbTransient annotation made allowed only on fields.
>
> This text is removed:
>
> "When placed on a class, indicates that the class shouldn't be mapped
> to JSON by itself. Properties on such class will be mapped to JSON
> along with its derived classes, as if the class is inlined."
>
>
> +1 while "fields" means field or property.
>
>
> 4. Removed 'smallest possible type' rule for number types. JSON number
> type is always mapped to BigDecimal in case target type is not
> specified. This is done to make numbers serialization and
> deserialization consistent. We always serialize java.lang.Number by
> converting it to BigDecimal first and we always deserializing JSON
> number type to BigDecimal if target type java.lang.Number or Object.
>
>
> Should we specify it? Didn't check lately but I think jsonp handles it so maybe better to not add rules we could conflict there.
>
>
> 5. @JsonbValue annotation is removed. Adapters should be used instead.
>
>
> sounds good
>
> Thanks,
> Dmitry Kornilov
>
>