23.07.2013 Views

Java IO.pdf - Nguyen Dang Binh

Java IO.pdf - Nguyen Dang Binh

Java IO.pdf - Nguyen Dang Binh

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

}<br />

<strong>Java</strong> I/O<br />

The main() method attempts to create an instance of this class, serialize it to a byte array<br />

output stream, then read it back in from a byte array input stream. However, here's what<br />

happens when you run it:<br />

D:\JAVA>java SerializableZipFileNot test.zip<br />

Wrote object!<br />

java.io.InvalidClassException: java.util.zip.ZipFile; <br />

at java.io.ObjectInputStream.inputObject(Compiled Code)<br />

at java.io.ObjectInputStream.readObject(ObjectInputStream.java:363)<br />

at java.io.ObjectInputStream.readObject(ObjectInputStream.java:226)<br />

at SerializableZipFileNot.main(SerializableZipFileNot.java:28)<br />

Since the superclass, ZipFile, is not itself serializable and cannot be instantiated with a noargument<br />

constructor, the subclass cannot be deserialized. It can be serialized, but that isn't<br />

much use unless you can get the object back again. Later, you'll see how to make a<br />

SerializableZipFile class that can be both written and read. However, to do this, you'll<br />

have to give up something else, notably the ZipFile type.<br />

11.5.1.3 Problem 3: Deliberate throwing of NotSerializableException<br />

A few classes appear to be not serializable out of pure spite (though normally there's more<br />

reason to it than that). Sometimes it's necessary, for security or other reasons, to make a class<br />

not serializable, even though one of its superclasses does implement Serializable. Since a<br />

subclass can't unimplement an interface implemented in its superclass, the subclass may<br />

choose to deliberately throw a NotSerializableException when you attempt to serialize it.<br />

You'll see exactly how this is done shortly.<br />

11.5.1.4 Locating the offending object<br />

When you encounter a class that you think should be serializable but isn't (and this happens<br />

all too frequently, often after you've spent two hours adjusting and customizing several dozen<br />

beans in a builder tool that now can't save your work), you'll need to locate the offending<br />

class. The detailMessage field of the NotSerializableException contains the name of the<br />

unserializable class. This can be retrieved with the getMessage() method of<br />

java.lang.Throwable or as part of the string returned by toString():<br />

try {<br />

out.writeObject(unserializableObject);<br />

}<br />

catch (NotSerializableException e) {<br />

System.err.println(e);<br />

System.err.println(e.getMessage() + " could not be serialized");<br />

}<br />

It is not always obvious where the offending class sneaked in. For example, if you're trying to<br />

serialize a hash table that contains seven vectors, each of which contains many different<br />

objects of different classes, a single nonserializable object in one of the vectors will cause a<br />

NotSerializableException. You'll need to explore the source code to determine which<br />

object caused the problem.<br />

246

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!