RFR(s): 8133977 add specification for serial form of immutable collections

Stuart Marks stuart.marks at oracle.com
Tue May 17 18:46:34 UTC 2016


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



More information about the core-libs-dev mailing list