Please review clarification of java.time serialized form

roger riggs roger.riggs at
Thu Sep 12 13:49:30 UTC 2013

Hi Stephen,

On 9/11/2013 8:56 PM, Stephen Colebourne wrote:
> HijrahChronology mixes "final transient"  and "transient final". They
> should be consistently one way or the other files should be checked,
> and I think there is an official coding standard for this).
Yes, will fix in a future update.
> Some classes have had transient added, while others haven't. For
> example LocalDate doesn't use transient. Since the instance fields are
> never directly serialized, but do appear in the serialized form,
> perhaps they should be marked as transient?
Marking as transient will make them disappear from the serialized form.
The comments on the individual fields seemed useful to document the data
in the stream and they were kept when the writeReplace method documented
writing them to the stream.    In other cases the writeReplace method refers
to the <get> method that returned the value instead of a field.

> The byte code numbers for MinguoDate and ThaiBuddhistDate are now out
> of line as you removed the ERA constants in Ser.
How should that be fixed, restore the gaps or re-order?

Thanks, Roger

> Otherwise looks like a good improvement.
> Stephen
> On 6 September 2013 20:06, roger riggs <roger.riggs at> wrote:
>> The specification of the serialized-form[1] of the java.time classes has
>> been
>> improved in response to issue 8024164: JSR310 serialization should be
>> described in detail
>>   - Add descriptions in the Ser classes of the mapping between the type bytes
>> and
>>     corresponding serialized classes.
>>   - Add missing specification of the serial data to writeReplace methods
>>   - Add missing readResolve methods that prevent deserialization from
>> improperly formatted streams.
>>   - The Era that are Enum's do not need customized serialization;
>>     remove unused writeReplace, writeExternal, and readExternal methods,
>>     remove unused java.time.chrono.Ser type codes for *Eras and renumber.
>> [1]:
>> Webrev:
>> Javadoc:
>> Please review and comment.
>> Thanks, Roger

More information about the core-libs-dev mailing list