Re: Serializing a non-Serializable class...
Please attribute your citations.
Lew wrote:
"Forced" to use a premier language and platform means that you are a lucky person.
KB wrote:
Sorry, didn't mean to offend anyone... O.o,
Huh?
nor imply I wasn't lucky, yet forced I am.
Did I forget to peg a smiley to my remark? Hmm, seems I did. That's what I
get for assuming people appreciate silliness. Next time I'll put up a big sign:
!!---------------------------!!
You are a lucky person . !! <== HUMOROUS INTENT HERE! !!
!!---------------------------!!
Lew wrote:
You can implement the serialization methods 'writeObject()', 'readObject()'
and perhaps 'readObjectNoData()', also perhaps 'writeReplace()' or
'readResolve()' manually for the class that composes your external class, or
KB wrote:
Would that mean I would need to have exposure to the whole class/
documentation for the whole class? I am afraid that is not possible
(due to I.P. contraints).
Probably not, although I cannot see how intellectual property constraints have
anything to do with it. You implement the readX() and writeX() methods for
your class to create an instance of the non-serializable class that has the
externally-visible properties that you want. If the IP restrictions prevent
you from using the public API of the class in question, then it's a pretty
useless class, isn't it?
Lew wrote:
alternatively use 'java.io.Externalizable' to wrap the external class and
implement its methods manually.
KB wrote:
That sounds interesting! Since I only have exposure to a few methods,
that maybe a possibility!
There's no difference between the two approaches ('Serializable' vs.
'Externalizable') as far as what methods and constructors you'd use from the
library class. The difference is in what methods you implement in your own
client class to accomplish the goal.
--
Lew