NX: serialization or not

[Rick Lu]

Hi,
I want to expose MetaData, used by Data.java, to clients, which I have to implement serializable interface. But SUN also said in local mode, it should be no any serialization of any objects. I don't know how to expose this object now! ( must need LocalMetaData & RemoteMetaData right? sounds too complex )
Another choice is to directly expose method instead of Object. But this seems not so OO.
Any suggestion for this ? Is there any simple and efficient way to do so???
Regards,
Rick

[Philippe Maquet]

Hi Rick,
Or I missed something in your question, or the way your client accesses any object should be transparent to your client code whatever remote or local. I think here of Proxy and Factory patterns ...
Best,
Phil.

[Jim Yingst]

My Data class has a getMetaData() method which returns a MetaData object. This fact that this object is Serializable enables me to return it from my RemoteDataImpl in RMI, but in local mode this is irrelevant. I just call getMetaData() and get the object. I'm not sure what you're asking here...

[Philippe Maquet]

Hi Jim,
I guessed that Rick uses sockets, meaning that it may look a little less obvious than with RMI. But once the network layer is abstracted (what I meant with Proxy + Factory), it should be exactly the same as what you describe in the RMI context.
Best,
Phil.

[Rick Lu]

Thank you guys. I uses RMI actually, but kind of lost in Serializable.

This fact that this object is Serializable enables me to return it from my RemoteDataImpl in RMI, but in local mode this is irrelevant. I just call getMetaData() and get the object.

This is exactly what I am asking for. The class MetaData is not serizliable? You did it only in RemoteDataImpl right? How can I do that? Thanks
Regards.
Rick

[Jim Yingst]

The class MetaData is not serizliable?
No, it is serializable. You can try omitting this declaration initially, but eventually rmic will complain that it can't create a stub class for a Remote interface if a return value or parameter type isn't Serializable, or a primitive type.
You did it only in RemoteDataImpl right?
I did it in the main Data class, and also in RemoteDataImpl (which simply calls Data's implementation, as it does for everything else).

[Rick Lu]

Hi Jim,

No, it is serializable. You can try omitting this declaration initially, but eventually rmic will complain that it can't create a stub class for a Remote interface if a return value or parameter type isn't Serializable, or a primitive type.

If you did serizlize the MetaData, then you cannot call this class in local mode because SUN don't allow call any serializable objects in local mode. Is that ture?
Rick

[Jim Yingst]

Well, Sun's API uses Strings for example, and those are Serializable, so I'd have to say that no, having a Serializable class is not a problem. It's a fairly harmless marker interface. I would say that ni local mode you shouldn't use any classes from the java.rmi or java.net package heirarchies, but Serializable ought to be perfectly OK.

[Jim Yingst]

Note also that nothing is actually serialized in local mode; the class just implements in interface that says it's OK if you do serialize it.
[ November 10, 2003: Message edited by: Jim Yingst ]

[Rick Lu]

Note also that nothing is actually serialized in local mode; the class just implements in interface that says it's OK if you do serialize it.

Is that true whether the object is serialized or not is automatcially controlled by required streams? I don't undertand this interface well becuase it only needs a interface marker, no method
Thank you, Jim.

[Rick Lu]

Hi,
Anyone can tell me whether the serialization is strem-oriented or not? That is, the stream will decide the object is serialized or not, right? Thus, in local mode, no seriablized objects will be created.
Thanks.
Rick

[Jim Yingst]

Anyone can tell me whether the serialization is strem-oriented or not?
Ummm, if you serialize something, you're writing it to a stream, by definition. However it's possible to use an object which is Serializable without actually serializing it.
That is, the stream will decide the object is serialized or not, right? Thus, in local mode, no seriablized objects will be created.
Mmmm, you have to write code which decides whether an object is serialized or not. E.g. if you create an ObjectOutputStream and call writeObject(), that will explicitly serialize an object. Or if you use RMI the system will create code which does serialization for you - this happens when you call rmic on a class. If you don't do one of these things, then serialization won't happen. So in local mode, don't use any ObjectOutputStream or ObjectInputStream, and don't call any classes that you invoked rmic on, and you'll be safe - you won't accidentally serialize anything, even if it says Serializable.
When you serialize an object, the stream does check to see if the thing that you're serializing implements Serializable (or Externalizable). If it doesn't, the stream throws an error. This can be thought of like this:

if (obj instanceof Serializable) {
    doSerialization(obj);
} else {
    throw new NotSerializableException();
}

In terms of actual code, the only thing that Serializable "does" is to allow an object to pass an instanceof test. That's it. What it means is, the person who wrote the class thought about it, and decided that it would be OK to serialize this object, either using the default serialization of ObjectOutputStream, or using a custom implementation provided in the class itself (as described in the Serializable interface). But the compiler and JVM have no way of knowing that - they just test if (obj instanceof Serializable) is true or false.

[Rick Lu]

Hi Jim,
Sun serializable FAQ says the serialization is stream-oriented, just found it.
And there is a way to know whether objects are serialized or not: using writeObject and readObject in the class which implments serializable interface.
Thanks for your reply. Now, I can use it without violating SUN's instructions.
Regards, Rick