Hi Oleg,
thank you for your comments! I will go through it asap.
Martin
On Tue, Jun 2, 2015 at 11:30 PM, Oleg Tsal-Tsalko <oleg.tsalko_at_gmail.com>
wrote:
> Hi guys,
>
> It's been for a while since our last email, so we have quite a few
> outstanding comments/questions reg JSON-B spec.
>
> I decided to provide majority of them in one email so it might be easier
> for you to comment on them since all of you pretty much in context of
> recent changes in spec including 'Customizing Mapping'. Also I grouped our
> comments/questions by topics:
>
> Forgotten stuff:
>
> 1) [TYPO] Runtime "Use an explicit implementation of JsonbProvider"
> example should be changed to explicitly instantiate provider instead of
> builder itself I believe.
>
> DefaultMappingGenerics:
>
> 2) There are still no examples to show use cases for Jsonb#toJson(Object,
> Type) method to deal with particular special cases where otherwise it
> won't work
>
> 3) [TYPO]
> assertEquals("{\"boundedSet\":[3],\"superList\":[{\"radius\":2.5}]}",
> jsonb.toJson(boundedGenericClass));
>
> missing area property of Shape super class I guess
> 4) In DefaultMappingGenerics examples we shouldn't use explicit asserts
> for LinkedHashMap default implementation of Map as we agreed to relax this
> constraint in spec as I remember
> 5) In DefaultMappingGenerics examples for incompatible types it will be
> ClassCastException later on instead of JsonbException
>
> DefaultMappingDates:
>
> 6) No negative test case examples to throw JsonbException if JSON
> date/time is not in supported ISO format
>
> SPEC:
>
> 7) Formally in 3.4.3 chapter it's not mentioned about ser/deser of
> Optional's as JsonValues, despite behavior is the same as for object
> instance properties
> 8) [TYPO] in JSB-3.6-1 java.math.Integer—Long—BigDecimal
> 9) In 'Scope and Field access strategy' 3.7.1 section nothing said about
> getters/setters without actual field as we have examples for it
> 10) In 'Null Java field' 3.14.1 section it is not explicitly stated about
> unmarshalling of null values from JSON and there is no such case in
> examples by the way
> 11) [TYPO] javax.json.bin. in several places in spec
> 12) @JsonbPropertyOrder annotation usage is not mentioned in spec
> 13) There is no word about @JsonbTransient annotation in spec
>
> CustomizingMapping:
>
> 14) Why @Retention is missed on @JsonbTransient annotation?
> 15) It is stated that @JsonbTransient is mutually exclusive with other
> annotations. What gonna happen if user specify contradictive annotation on
> field lets say?
> 16) I suspect in CustomMapping#toJson_nillable() examples it should be
> 'null' instead of 'nill' values?
> 17) I think JsonConfig#withSkippedNullValues should really be
> #withNullValues and there is no mentioning of default value in Javadoc
> which should be 'true' in this case because we are skipping null values by
> default?
> 18) There is no example of @JsonbProperty usage on Parameter level and
> I'm not sure it's required IMO. Only one valid usage I can think of is
> together with @JsonbCreator methods/constructors which hasn't been agreed
> yet.
> 19) Do we really feel strong need in @JsonbCreator functionality? If yes,
> it should probably be integrated in main default mapping spec chapters
> rather then simply in customization mapping chapter, cause it influence
> constraints for POJOs being deserialized. WDYT?
> 20) There are no examples of @JsonbValue usage which might be ambiguous
> IMO. Will be good to hear some good use cases justifying it? Also same
> effect could be achieved using TypeAdapters.
>
> 21) [TYPO] public identifiers from
> PropertyNamingStartegy/PropertyVisibilityStrategy interfaces should be
> removed to be consistent
> 22) There are no examples of JsonbVisibilityStrategy usage and again I
> don't feel it's really needed. I would rather relax constraints for public
> class members in first place. However even if we do want to have it,
> probably it's better to define some meaningfull default strategies here if
> you can think of any?
> 23) BinaryDataStrategy could be an enum?
> 24) In PropertyOrderStrategy I would rename REFLECTION constant to FIELDS
> and update corresponding javadocs to not rely on some particular reflection
> API method as stated in javadocs currently
> 25) Don't we want to introduce smh like JSONB_STRICT_DESERIALIZATION
> config param to handle missing JSON properties differently than default
> skip strategy and corresponding @JsonbStrictDeserialization annotation on
> TYPE level?
> 26) JSONB_EVENT_HANDLER could be removed in JsonbConfig class
>
> Thank you,
> Oleg
>