Use the Class.forName(s, false, cl) method instead of the ClassLoader.loadClass(s), where
"s" is a name of array type, "cl" is a class loader.
Just to be clear, this is not a bug in ObjectInputStream-- the problem is that when the user's anonymous subclass of ObjectInputStream overrides resolveClass to load deserialized classes from the specific class loader, it uses the ClassLoader.loadClass instance method, which does not (necessarily) support loading array classes, instead of using the static three-argument Class.forName method (like ObjectInputStream's own implementation of resolveClass uses). The Class.forName methods do support loading array classes using the same array class name syntax returned by Class.getName and thus also by ObjectStreamClass.getName.
[When you want to reflectively load a class by name initiated using a specific class loader, you should not invoke that loader's public loadClass method directly-- instead, you should always use the static three-argument Class.forName method. The ClassLoader.loadClass instance method is more intended for delegation from one class loader to another within a class loading operation (although this is a common confusion and not well described in the documentation). In other words, replace L.loadClass(N) with Class.forName(N,false,L). The Class.forName invocation may eventually end up invoking loadClass on the specified loader, but only after taking care of some other aspects of the VM's standard symbolic class name resolution process-- the significant bit in this case being the support for loading/creation of array classes.]
The fact that the ClassLoader.loadClass usage sometimes worked with array class names in previous versions was considered a bug (unintentional behavior) that got fixed in Mustang-- and it did not previously actually "work" fully reliably anyway, which is part of the reason that this "bug" was fixed. There is some related discussion in the text of CR 4976356, and for some further discussion related to serialization usage, see this JINI-USERS post:
Even though this issue is not a bug in ObjectInputStream, the fact of the difference in behavior of ClassLoader.loadClass is currently open as 6434149, so this CR has been marked as a duplicate of that one.