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.
s'marks
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...
Thanks,
-Andrew
-----Original Message-----
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> On Behalf Of Zheka
Kozlov
Sent: Monday, December 3, 2018 12:43 AM
To: Ivan Gerasimov <ivan.gerasi...@oracle.com>
Cc: core-libs-dev <core-libs-dev@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.gerasi...@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,
Ivan
On 12/2/18 9:27 PM, Tagir Valeev wrote:
Hello!
Please review and sponsor the optimized implementation of
Collections.nCopies().hashCode():
https://bugs.openjdk.java.net/browse/JDK-8214687
http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/
Previous discussion thread:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-November/056
843.html
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
