RFR(m): update 2: JEP 269 initial API and skeleton implementation (JDK-8139232)

[Stuart Marks]

Hi Chris,

Yes, absolutely, my plan is to introduce a serial proxy in a subsequent round of 
changes. The serial proxy will be the only new serial form introduced; the 
optimized implementations won't have a serial form of their own exposed.

The skeleton implementations are in fact serializable but their serial forms 
aren't final. It didn't seem worthwhile to go to the extra effort to shut this 
off. I've asked the JCK team not to write serialization tests until the serial 
proxy stuff gets integrated.

s'marks




On 12/7/15 3:29 AM, Chris Hegarty wrote:
>
>   102  * <li>They are serializable if all elements are serializable.
>
> To avoid any ambiguity or "leaking", would it make sense to
> have the serial form of these types be defined, in a similar
> manner to what was done for Serializable types in the
> java.time package [1].
>
> This can be done as a follow up, so as to not block your
> progress.
>
> -Chris.
>
> [1] https://docs.oracle.com/javase/8/docs/api/serialized-form.html#java.time.Ser.
>
> On 04/12/15 00:58, Stuart Marks wrote:
>> ...
>>
>> I still need an official OpenJDK Reviewer.
>
>> API:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151203/
>>
>> Specdiff:
>>
>>
>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151203/overview-summary.html
>>
>>
>>
>> Webrev:
>>
>>      http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151203/
>>
>> Thanks,
>>
>> s'marks
>>
>>
>> On 12/1/15 6:35 PM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Thanks for the previous round of review comments. Here's an updated
>>> API and
>>> implementation for review.
>>>
>>> I've run specdiff with the --hu ("hide unchanged") option, so only the
>>> bits of
>>> the specification that have changed are shown. As before, though,
>>> please ignore
>>> the spurious change to EnumSet caused by a javadoc bug.
>>>
>>> API changes:
>>>   - add clarifying notes on immutability
>>>   - remove wording that implied creation of new objects
>>>   - add "value-based" disclaimers
>>>   - add ordering specification for List and non-ordering disclaimers
>>>     for Set and Map
>>>   - clarify that Map.ofEntries() doesn't store the Map.Entry objects,
>>> instead
>>>     it extracts keys and values
>>>   - Map.Entry instances returned from Map.entry() are *not* serializable
>>>
>>> Other:
>>>   - markup cleanups
>>>   - small implementation cleanups
>>>
>>> JEP:
>>>
>>>      http://openjdk.java.net/jeps/269
>>>
>>> API spec (basically List, Map, and Set):
>>>
>>>      http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151201/
>>>
>>> Specdiff:
>>>
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151201/overview-summary.html
>>>
>>>
>>>
>>>
>>> Webrev:
>>>
>>>      http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151201/
>>>
>>> Thanks,
>>>
>>> s'marks