On 5/17/16 1:55 AM, Stephen Colebourne wrote:
Stuart, I disagree with using an int for the flags, it should be a byte. If
you need future expansion you can use 0xff to indicate it with the parser
reacting accordingly. That is the strategy for JSR 310
These techniques have different goals.
I don't see 0xff used at all in the current java.time.Ser class. (Did I miss
something?) What I think you mean is that, in a future JDK, a sentinel value
like 0xff could be used as the type value, indicating the presence of some
additional or changed values following in the data stream.
That's fine, but such usage is necessarily forward-incompatible. By this I mean
that the JDK 8 implementation of java.time.Ser is incompatible with a future
JDK's serialized form that uses this new 0xff type value (or in fact with any
other new type value). Deserializing such a thing on JDK 8 would result in an
exception. That might be exactly what you want, if some future java.time class
cannot possibly be handled on JDK 8.
For the proposed java.util.CollSer, exactly the same technique would apply by
using a different "kind" value in the low order 8 bits. A future JDK might have
some new kind of collection that can't be represented in JDK 9. The future JDK
would use a new "kind" value, and deserializing it on JDK 9 should throw an
exception.
The other 24 bits are for *forward compatible* uses by future JDKs. Suppose a
future JDK has a variation on List that uses a different internal storage format
that works better in some cases. The future JDK might want to set a hint
somewhere when serializing it, so that another instance of a future JDK could
pick up this hint when deserializing. If a JDK 9 were to deserialize this, it
would ignore the hint and deserialize an ordinary (immutable) List.
It's always possible for a serialized form to add fields, which are specified to
be ignored by older versions. But sometimes you don't want to add an entire new
field, and you just need an extra bit. That's what the extra bits in the flags
field are for.
s'marks
