Hi Przemyslaw,
please see my comments below.
On 24.02.15 9:36, Przemyslaw Bielicki wrote:
> Hi,
>
> I have few questions regarding POJO. What worries me is the need for
> default constructor.I would add @JsonbType annotation similarly to
> @XmlType in which we have to specify factory class and/or factory
> method. For many cases default constructor is enough but as soon as
> you want your objects to be managed by CDI / Spring you have a
> problem.
Agree. As of now, we've been looking into the default instantiation
mechanism using default mapping only.
We will be designing support for this usecase within
https://java.net/jira/browse/JSONB_SPEC-25
> If we supported Java 8 we could also add method with
> java.util.function.Supplier<T> parameter that would be the most
> elegant option IMO. Unfortunately in this JSR we are not supposed to
> be aware of Java 8 :)
Actually, EE 8 minimal requirement is Java 8, and most (if not all) EE
specs are adopting SE 8 so I think we all already agree it makes sense
to relax this requirement.
> Another aspect is the naming of attributes. You assumed camel case
> naming? E.g. private String name; will become "name" in JSON. What
> about private String firstName; ? What if I don't want camel case but
> underscore separator e.g. "first_name"? I think it would be nice to
> let JSON-B users define their naming convention globally using
> JsonbConfig and per class using annotations.
Right, naming algorithm shall be specified within
https://java.net/jira/browse/JSONB_SPEC-16 and its customization within
https://java.net/jira/browse/JSONB_SPEC-17
> For the unmarshalling we could even add option to ignore case e.g.
> "name", "NAME", "NaMe" could be equal.
JSON is case sensitive, thus I'd rather see this as an implementation
specific thing?
> For null handling I would like to have Optional<T> but it's again Java
> 8 and later. Anyway, I hope we will be able to add support for
> Optional<T> as a plugin later on, because it would be very very
> beneficial.
The trouble with Optional is that it is typed, and as such its use is
too complex within the api methods we have now compared to the minimal
benefit it brings.
MartiNG
> Cheers,
> Przemyslaw
>
> On Fri, Feb 13, 2015 at 8:26 PM, Martin Vojtek <martin.vojtek_at_oracle.com> wrote:
>> Hi,
>>
>> I have pushed new branch default_mapping, which contains initial examples for default mapping.
>>
>> There are also comments, which contain information about concepts like null handling and default field access strategy.
>>
>> Default mapping of dates and generics handling is not part of this commit and will be addressed separately.
>>
>> Looking forward to your feedback.
>>
>> Thank you,
>> Martin Vojtek