CustomObjectInputStream's readInt throws a cast error if the read data is a Byte.

[thxwelchs]

https://github.com/x-stream/xstream/blob/d03f6987b793fac71ab89a31d7aa633c366c5289/xstream/src/java/com/thoughtworks/xstream/core/util/CustomObjectInputStream.java#L164

(Integer) Byte cannot be converted to an Integer when an explicit cast is attempted. I wonder why this was implemented this way.

[joehni]

Actually I don't understand the question. This is how Java Serialization works: If you have written a Byte into the object stream, you will have to read a Byte again. It will not miraculously turn into an Integer, just because you do now try to read one. You broke the API contract.

[thxwelchs]

@joehni Thank you for your feedback. I know about the Stream API contract. But The problem is that if the type read from the stream is bytes, explicit conversion to a reference type integer will result in a cast error.

I think it should be modified as shown in the example, but if I'm not understanding about this feature, please let me know.

return ((int)peekCallback().readFromStream());

return peekCallback().readFromStream().intValue(); // Convert Byte to int (auto-unboxing followed by implicit casting)

[joehni]

Maybe you should also have a look at CustomObjectOutputStream, then you'll see, that the custom implementations of XStream will only write objects, since the representing tag (e.g. "int") in XML does not differentiate between the native and the boxed type, they are represented in the same way. However, if the method readInt() has been called, the (XML) stream must contain an Integer object, that is returned unboxed again.

[thxwelchs]

Maybe you should also have a look at CustomObjectOutputStream, then you'll see, that the custom implementations of XStream will only write objects, since the representing tag (e.g. "int") in XML does not differentiate between the native and the boxed type, they are represented in the same way. However, if the method readInt() has been called, the (XML) stream must contain an Integer object, that is returned unboxed again.

Thanks for the detailed explanation. I understood what you were saying, that the output stream is written as an integer type rather than a byte

I faced this problem indirectly with Spring Batch, which is using XStream. SpringBatch serializes the metadata information to XStream, but it seems to do it as Byte instead of object.

[joehni]

I don't use Spring, but in this case they are using the API of Java Serialization and this means, they must read the same types in the same sequence that they had written it before.

Now, what might have happen is, that the persisted XML has been written with a different version of the application or the Java runtime, where the serialization for an object had been changed in between (e.g. a new field in a serialized object). However, in that case it is no real limitation of XStream, but of Java serialization itself, i.e. you would have faced the same problem using Java Serialization natively.

Normally such problems can be tackled by directly implementing Java serialization functions in the affected classes, that handle the differences from an older representation, but that's typically never done... and may it be just because most devs are not even aware of such problems.

[joehni]

BTW: Just using a formatter that sorts the members of a class into a different order might cause such problems...