mjunsilo edited a comment on pull request #66: URL: https://github.com/apache/uima-uimaj/pull/66#issuecomment-709963108
I actually don't have detailed understanding of this flag, except from what I have picked up from the comments. Marshall introduced it in 2016 with the following original comment "If true, adjust type codes in serialized forms to allow v2 type codes to be correctly read by v3 impls, because v3 impls have a greater number of built-in types". One year later this comment was just reduced to "used to calculate total heap size". The variable is only used in BinaryCasSerDes6.deserializeAfterVersion where it appears to be used in some heap calculations, but my understandings of the low level workings of the CAS are too limited to understand what exactly happens. Obviously there seems to be a difference between v3 and v2 in heap allocation that the deserialization must take into account. As already pointed out, it is currently not vital to clear this flag with the changes I made, and adding unit tests that captures the issue would help. My problem is that I don't know how the use of this flag changes in the future, so I currently feel more safe with the clearing as an extra insurance. I am not sure I can reproduce the exact same problems as those we had with a small test example. We experienced two different behaviours for v2 and v3 CAS when this flag was incorrectly set. Deserialization would fail with an EOF exception in the case of v2, but it would succeed with v3, except that most annotations were missing. Currently these problems only occur when you are running an application in the CPE, or similar environment where the CAS is recycled using reset, and both v2 and v3 CAS versions will be loaded during the lifespan of the application. In our case this is an elaborate integration test, and I initially thought the problem was maybe more general until I found the root cause and a fix. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
