Hum I don't see either, anyway the mapping to optional will be provided by
impls.
Le 24 févr. 2015 12:50, "Oleg Tsal-Tsalko" <oleg.tsalko_at_gmail.com> a écrit :
> 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
>>>>
>>>
>