How do we create a duplicate copy of an user defined class OBJECT
without using cloning..
because user defined class object has references to ArrayLists...and several other data types which cannot be cloned.
And i don't want to use serialization because it involes writing to files and reading from files......
You'd do it one of three ways, I think:
1. Use piped streams to write out and then read back in a serialized copy of the object (which requires that the object in question be Serializable).
2. Create an interface which declares a duplicate() method with your own constraints and require the provided data to implement that interface.
3. Require the object to be Cloneable (which you just said you don't want to do).
The advantage of the first is that individual classes likely need no special handling. You can duplicate Strings, Integers, and what have you in this manner as long as they all implement Serializable. Unless they do, you can't use serialization, so duplicating some kinds of objects (such as Sockets) won't be possible.
The advantage of the second is that you can control exactly the requirements of the method. You don't have the problem with serialization which prevents you from making copies of objects if any of their superclasses aren't serializable (again, see Socket). However, you do have to specify some means by which library classes are to be incorporated into this framework and you have to specify the means of duplication on every class.
The advantages of the third are much the same as the second with the added bonus of not having to worry about library classes. However, like you already pointed out, you don't want to do it this way. I thought I might point it out for completeness.
I would strongly recommend considering Cloneable for this purpose. Either way, you have to have the class implement something and serialization is not exactly fast. You could achieve a great deal more efficiency if you avoided the serialization approach.
Of course, that depends on your requirements. Good luck, regardless. :)
> You don't need a piped stream, you can use
> ByteArrayInput/OutputStreams.
Quite granted. That is, of course, assuming that creating a duplicate copy in the byte array and then a third copy in memory (the actual copy) won't be a problem.
'course, using piped streams assumes that making another thread to facilitate the copy wouldn't be a problem. :)
But yeah... byte array streams are easier.
Ohhhh.... yeah, I agree with you completely there. I was thinking about memory consumption.
After this discussion, it has become apparent to me that, in general, the byte array streams are going to be a better choice. But yeah, a third copy will definitely occur regardless of what you do with those streams.