Uber-project for foundational modules of Jackson that build directly on core components but nothing else; not including data format or datatype modules
Apache License 2.0
167
stars
77
forks
source link
Consider changing checks for `is std (de)serializer` for `BeanPropertyWriter` #15
Currently any deserializer/serializer that is not considered Jackson "standard" (de)serializer will lead to de-optimizing access. However, it should really only be necessary to do this for cases where handling would markedly differ:
String (the original reported problem, issue 59 (in old repo))
int/Integer
long/Long
boolean/Boolean
whereas other Object types seem unlikely to have problems due to optimized access.
The reason for being more selective is because there is some cost from de-optimizing; namely additional method call due to chaining, as well as loss of optimization itself.
At this point, not 100% sure what would be needed here. But a minor code change for 2.9.6 will ensure that at least super-sonic bean (de)serializer is not accidentally optimized away.
Currently any deserializer/serializer that is not considered Jackson "standard" (de)serializer will lead to de-optimizing access. However, it should really only be necessary to do this for cases where handling would markedly differ:
String
(the original reported problem, issue 59 (in old repo))int
/Integer
long
/Long
boolean
/Boolean
whereas other Object types seem unlikely to have problems due to optimized access.
The reason for being more selective is because there is some cost from de-optimizing; namely additional method call due to chaining, as well as loss of optimization itself.