Agree, we just nees to ensure to not expose more than today internals probably but i dont see any blockers :)
Le mar. 1 janv. 2019 17:26, James Carman <ja...@carmanconsulting.com> a écrit : > Well, ideally, the recursive one and the root one would use the same logic > to map a JsonValue/JsonNumber -> Integer object, right? Perhaps we need to > converge all this together and save ourselves some code. > > On Tue, Jan 1, 2019 at 11:19 AM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > Hi James > > > > I likely need test cases to understand more the issue but long story > short > > one of the two method is recursive not the other so one must handle > > primitives as root types and the other aq nested type. Historically > > primitives were not possible root types so can be something to refind. > > > > Happy to review Jira+pr to be more accurate if needed. > > > > Le mar. 1 janv. 2019 16:31, James Carman <ja...@carmanconsulting.com> a > > écrit : > > > > > I am looking at JOHNZON-177 and I have noticed that we seem to be > mapping > > > primitives inconsistently inside the same class. > > > MappingParserImpl.toObject() and MappingParserImpl.readObject() both > > > contain special logic for handling longs and ints. Why wouldn't we > want > > to > > > handle these types consistently regardless of where they're used > (fields > > or > > > the root type)? > > > > > > I have included code to handle the overflow/underflow case with a nice > > > error message and that works fine when I added tests to the > > > DefaultMappingTest from the JSON-B module. However, I found that > > > MapperTest seems to already have similar tests for invalid long/int > > > values. As I trace the logic, it doesn't hit my new code. > > > > > >
