Does Array implement Serializable?

[Marcus Kelvin]

So I have some study material with sample code which includes this:

int[] ray = {1, 2, 3};
Serializable ser = ray;

The point of the example was just to demonstrate some things about interfaces, inheritance, and assignment -- beyond this point "ser" is not used. But I know what serialization is and was curious about the interface. Eventually I got it to work (altho I didn't check the binary output*). Does this mean Array implements Serializable? If not, why does this work? Or have I fooled myself?

I'm not sure because: I then tried assigning a object instance from a class which does not implement Serializable. This compiled fine:

	try {
		FileOutputStream fos = new FileOutputStream(FileDescriptor.out);
		ObjectOutputStream oos = new ObjectOutputStream(fos);
		oos.writeObject(inappropriateObj);
	} catch (IOException whoops) {
		System.err.println("EXCEPTION" + whoops.toString());
	}

At runtime, the code in the catch block doesn't happen. I got binary data with text in it, which I guess might be "inappropriateObject" (the class is a dummy class with one simple method) but includes "java.io.NotSerializableException" several times. What's going on here?

* [edit] so I've looked at it in decimal dump viewer and am not so sure, I guess I would have to read it back in to confirm.

[Campbell Ritchie]

It wouldn’t have compiled if an array (not Array) didn’t implement Serializable. For this sort of question, you should always query the Java Language Specification.

[Campbell Ritchie]

If one of the fields of the class, or one of the elements of the array, does not implement Serializable, then the serialised file will have the name of that Exception in. All the fields must implement Serializable in order for serialisation to proceed successfully, otherwise you will have an incomplete object. Remember that transient and static members are omitted from a serialised object.

[Jeff Verdegan]

Marcus Kelvin wrote:So I have some study material with sample code which includes this:

int[] ray = {1, 2, 3};
Serializable ser = ray;

The point of the example was just to demonstrate some things about interfaces, inheritance, and assignment -- beyond this point "ser" is not used. But I know what serialization is and was curious about the interface. Eventually I got it to work (altho I didn't check the binary output...). Does this mean Array implements Serializable?

Yes, Java arrays implement Serializable. Note, though, that they are not of class "Array".

I'm not sure because: I then tried assigning a object instance from a class which does not implement Serializable. This compiled fine:

Right, because the check for implementing Serializable happens at runtime.

	try {
		FileOutputStream fos = new FileOutputStream(FileDescriptor.out);
		ObjectOutputStream oos = new ObjectOutputStream(fos);
		oos.writeObject(inappropriateObj);
	} catch (IOException whoops) {
		System.err.println("EXCEPTION" + whoops.toString());
	}

At runtime, the code in the catch block doesn't happen.

Yes it does, if inappropriateObj does not implement Serializable.

Also, note that you never need to call toString() inside a println() method, or when concatenating with another String.

Also, note that it would be better to call whoops.printStackTrace() to get more details about what went wrong and where. Not a big deal here, but in more complex code, it will help a lot.

[Marcus Kelvin]

Campbell Ritchie wrote:It wouldn’t have compiled if an array (not Array) didn’t implement Serializable. For this sort of question, you should always query the Java Language Specification.

That's what I would have assumed, until I tried it with "inappropriateObject", which definitely does not implement Serializable, and that compiles fine. Why?

Jeff Verdegan wrote:
because the check for implementing Serializable happens at runtime.

Ah. Okay. So this is sort of an exception to the rule...how does it work?

[Jeff Verdegan]

Marcus Kelvin wrote:
That's what I would have assumed, until I tried it with "inappropriateObject", which definitely does not implement Serializable, and that compiles fine. Why?

Jeff Verdegan wrote:
because the check for implementing Serializable happens at runtime.

Ah. Okay. So this is sort of an exception to the rule...how does it work?

Look at the docs for writeObject(). It takes Object as an arg, not Serializable. So the check cannot occur at compile time. I'm not sure why it was written that way.

Note that it's always possible to do the check at compile time, but, as much as possible, we rely on Java's typing rules to do it at compile time for us. In this case, because they chose to have the method accept an Object rather than a Serializable, they gave up the compile-time check.

[Campbell Ritchie]

It’s probably a mistake that writeObject() takes Object as a type rather than Serializable.

[Jeff Verdegan]

Campbell Ritchie wrote:It’s probably a mistake that writeObject() takes Object as a type rather than Serializable.

It certainly seems like one to me. But then, it's so glaring, that I figure there had to be a good reason for it. My best guess is that it stems to a few picoseconds after Java's Big Bang, when everybody was still figuring out the lay of the land, and there probably was, or seemed to be, a good reason for it at the time, and then once things cooled and solidified, it was too late to change it without breaking lots of stuff.

[Paul Clapham]

I've never done it myself, but I see in the serialization tutorials that you can customize how an object is serialized by overriding its class's writeObject method in a peculiar way. So I assume that this customization could do anything it wanted, and that it would be run instead of the normal object serialization. In that case it could be applied to any type of object regardless of whether it implemented Serializable or not.

[Winston Gutkowski]

Jeff Verdegan wrote:it stems to a few picoseconds after Java's Big Bang, when everybody was still figuring out the lay of the land, and there probably was, or seemed to be, a good reason for it at the time, and then once things cooled and solidified, it was too late to change it without breaking lots of stuff.

Wow. A Brief History of Java.

Winston