RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()
stuart.marks at oracle.com
Tue Dec 4 03:24:44 UTC 2018
The general rule for JDK core classes (including collections, even private
implementations) is that we try to preserve backward *and* forward serialization
compatibility. This doesn't apply to all classes in the JDK, though. For
example, javax.swing.JComponent is serializable, but it includes a disclaimer
about potential serialization incompatibilities with future versions of itself.
On 12/3/18 11:06 AM, Andrew Luo wrote:
> CopiesList is private anyways, so are you suggesting that someone might call nCopies(0) in a previous version of the JDK, serialize the return value, and then unserialize in a later version of the JRE? Is this even a supported use case (serialization/deserialization of JRE classes across versions)? It was always my understanding that you can only unserialize JRE classes of the same version, since the internal class definition can change at any time...
> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf Of Zheka Kozlov
> Sent: Monday, December 3, 2018 12:43 AM
> To: Ivan Gerasimov <ivan.gerasimov at oracle.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()
>> Would it make sense to use CopiesList only for n > 0
> This can break serialization. When CopiesList(0, e) is serialized and deserialized back, it will be in an invalid state.
>> I believe it makes sense to override CopiesList.equals()
> Also: contains(), iterator(), listIterator()
> пн, 3 дек. 2018 г. в 14:19, Ivan Gerasimov <ivan.gerasimov at oracle.com>:
>> Thank you Tagir!
>> I think your solution is quite clever, and the fix looks good.
>> While we are here: Would it make sense to use CopiesList only for n >
>> 0, and make nCopies() and nCopies().subList() return
>> Collection.emptyList() otherwise?
>> This would allow to remove the check for n == 0 in a couple of places.
>> Also an unnecessary reference to the `element` wouldn't be kept.
>> With kind regards,
>> On 12/2/18 9:27 PM, Tagir Valeev wrote:
>>> Please review and sponsor the optimized implementation of
>>> Previous discussion thread:
>>> Thanks to Zheka Kozlov for the original proposal. Also thanks to
>>> Ivan Gerasimov for the simplification idea: (x & 0x8000_0000) != 0
>>> => x < 0.
>>> With best regards,
>>> Tagir Valeev
>> With kind regards,
>> Ivan Gerasimov
More information about the core-libs-dev