Safe copying

Question

Hello all.
I'm trying to create an application to produce arithmetic functions that use a generic Guess interface, but I'm not sure how to ensure that I have a "clean" Guess object for my calculations. A simple object reference could originate from a source I don't trust and therefore be attacked during the calculation. I'm therefore trying to work out if it's possible to make a defensive copy of an Interface class whose implementation I don't know.
I've settled on the idea of an abstract class that implements the Cloneable interface as well as Guess, with a 'protected final' clone() method that simply calls super.clone() (ie, Object's).
Is this sufficient, or will it simply return a binary copy of my abstract class whatever subclass it's called from because it's declared final? There seems to be very little info on the mechanics of the Cloneable interface and exactly how this works.
Alternatively, has anyone else run into this problem and, if so, how did you solve it?
Thanks in advance, and apologies to anyone who saw this before. I think I posted it under the wrong topic.
Winston

Answer 1

how a shallow copy addresses your
security concernsIt actually doesn't. For that I would have to copy the entire object tree generically (it can be done with reflection, but it's awfully tedious).
what 'a class written to
corrupt its user regardles of whether it's copied or
not' might be, or what 'would have to share any
damaging internals with every instance ever created'Any class can be made to corrupt a user by simply including references
to mutables which can then be changed by the cracker to affect behaviour. As you correctly point out, this can't be prevented by a shallow copy, only a deep one.
It sometimes happens by accident (eg, Date, which is why Calendar is now recommended), but if the source is trusted (as with Date) you can prevent a client from gaining access to your Date by simply copying it. Joshua Bloch talks about it in great detail in 'Effective Java',
including things like making sure you 'sanitize' BigIntegers and
BigDecimals to make sure they aren't some untrusted subclass.
but if you've got security concerns about an
externally derived class, a security manager and a
security policy for that codebase is the answer.I'll definitely give it a look. I think for the moment I'm simply going to keep things package-private, get the sucker developed, and then worry about how I can deploy it for others to add to.
Thanks very much for your comments.
Winston