NPE when parsing UTF-32 byte arrays about jackson-core HOT 7 CLOSED

Apologies for the bug & congratulations for being the first UTF-32 user I have ever met! ;-D
(I assume no one has used it before, given that this is the first bug report... and for quite a fundamental bug).

from jackson-core.

Interestingly the existing UTF-32 tested was NOT catching this issue, because it closed the stream before hitting end-of-file (which would trigger read). I was able to 'fix' this by checking for one more nextToken().
And with that, should be easy enough to fix the issue itself too.

from jackson-core.

Fixed, now passes modified unit test. Will be in 2.1.2, 2.2.0.

from jackson-core.

FWIW, patch fix list at: wiki.fasterxml.com/JacksonRelease212

from jackson-core.

Well, technically I'm not a UTF-32 user, I was just writing tests that ensured that Play framework lets Jackson detect the encoding, and included UTF-32 for completeness:

https://github.com/jroper/Play20/blob/1a467984ecd15c9f3ede8b245abb70cf4ce20184/framework/test/integrationtest-java/test/test/WsTest.java#L63

We're actually still on Jackson 1.9, but it's easy enough to work around by wrapping the byte array in a ByteArrayInputStream, so we don't need this backported.

from jackson-core.

Fair enough, I was guessing you were probably just testing UTF-32 handling for sake of completeness. :-)
(and remembered your name from earlier submissions)

If work-around is easy, that's good; but if you do want a fix, 1.9 branch is still open. Actually, come to think of that now, how about I'll see if I can just add the fix myself. It should merge relatively cleanly.

from jackson-core.

Fixed for 1.9.12 as well now.

from jackson-core.