Hi guys,
I didn't get where we were going to use Optional<T> class and what's the
complexity of it's usage in general?
Regards,
Oleg
2015-02-24 17:11 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com>:
> 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
>>>
>>