You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ok so something I figured might never occur -- number of MapperFeature fields filling int -- seems to be happening. Although with 3.0 we can remove/refactor some of them, this will not help 2.x, and we probably still need to add couple more in 2.x timeframe. Because of this, it probably makes sense to upgrade internal bitfield to use long: it should be mostly fine (I think there is just one theoretical gnarly part), and should go in 2.13.
The text was updated successfully, but these errors were encountered:
Implemented: the main/only potential concern is with frameworks -- if there is any way that configurator in, say, Spring, might be using MapperFeature.getMask() or enabledIn(int)...
I hope 2.13.0 release candidates can help there.
Ok so something I figured might never occur -- number of
MapperFeature
fields fillingint
-- seems to be happening. Although with 3.0 we can remove/refactor some of them, this will not help 2.x, and we probably still need to add couple more in 2.x timeframe. Because of this, it probably makes sense to upgrade internal bitfield to uselong
: it should be mostly fine (I think there is just one theoretical gnarly part), and should go in 2.13.The text was updated successfully, but these errors were encountered: