Code review request for 6990094 "ObjectInputStream cloneArray doesn't handle short[]"
Peter Jones
pcj at roundroom.net
Mon Dec 6 07:30:18 UTC 2010
Joe,
On Dec 3, 2010, at 11:06 AM, Joe Darcy wrote:
> Please review this simple fix for
>
> 6990094 "ObjectInputStream cloneArray doesn't handle short[]"
> http://cr.openjdk.java.net/~darcy/6990094.0/
>
> The complete patch is
>
> --- old/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800
> +++ new/src/share/classes/java/io/ObjectInputStream.java 2010-12-03 00:31:24.000000000 -0800
> @@ -3498,8 +3498,8 @@
> return ((int[]) array).clone();
> } else if (array instanceof long[]) {
> return ((long[]) array).clone();
> - } else if (array instanceof double[]) {
> - return ((double[]) array).clone();
> + } else if (array instanceof short[]) {
> + return ((short[]) array).clone();
> } else {
> throw new AssertionError();
> }
Ouch, I recall reviewing this code when it was added, but evidently missed this. FWIW, the change looks good to me [peterjones].
> You'll notice there is no regression test for this change. One justification is that the fix is in the "obviously no bugs" category. [1] There is an if-else instanceof chain over Object arrays and arrays of each primitive type; there are two checks for double and none for short so changing the one of the double checks to short is "obviously correct."
Agreed.
> Also, I've taken a stab a writing an explicit regression test for this condition, but the problem only manifests in cases beyond my direct serialization experience where a class has overridden the readUnshared method.
I think that there was a test to go along with the bug fix that added this code (although evidently it didn't cover the short[] case). I don't see it in the hg repository now, I wonder if that's because the bug had the security keyword.
Regards,
-- Peter
More information about the core-libs-dev
mailing list