AsyncXMLStreamReader#getLocationInfo().getEndingCharOffset() always -1

[sco0ter]

AsyncXMLStreamReader#getLocationInfo().getEndingCharOffset() always -1

[cowtowncoder]

That is expected behavior since only one of char/byte variants will ever provide actual information.
Type depends on input source itself: when given byte source like InputStream, only byte offsets are available; when char source like Reader, char offsets.
Async readers are always byte-based so only byte offsets are available.

The reason for this is because of costs involved in keeping accurate offsets -- native offset (byte or char) is needed for decoding, with little to no additional, but the "other" offset is either expensive to obtain (re-encoding to go from char to byte), or would need to be kept track on unit-by-unit basis (since decoding of char from byte is not separate step but integral part of processing from byte stream to tokens).

In case of async parsing, then, the only way to find character offsets would be for caller to keep track of buffers and then decode on as-needed basis.

[sco0ter]

Thanks for your explanation. You are right, probably to costly to have that feature by default.

[cowtowncoder]

@sco0ter Processing overhead is part of it, but keeping track would add a lot to complexity unfortunately. If there was a modular way to do it that'd be possible but... unfortunately no, at least the way implementation works.