Groups > comp.lang.java.programmer > #32934

Re: What goes wrong with cloning here

Path	csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From	Cecil Westerhof <Cecil@decebal.nl>
Newsgroups	comp.lang.java.programmer
Subject	Re: What goes wrong with cloning here
Date	Sat, 24 Oct 2015 01:44:40 +0200
Organization	Decebal Computing
Lines	187
Message-ID	<87fv11kv4n.fsf@Equus.decebal.nl> (permalink)
References	<87oafplh3t.fsf@Equus.decebal.nl> <87pp05k1h5.fsf@gnu.org> <87k2qdkxlh.fsf@Equus.decebal.nl>
Mime-Version	1.0
Content-Type	multipart/mixed; boundary="=-=-="
Injection-Info	mx02.eternal-september.org; posting-host="528adfd6ad074c92fdc6a7f8fb9e23d8"; logging-data="3271"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+3lM8NQwz764FDwvTY3Tx+/O2LCF/AN+I="
User-Agent	Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
X-Homepage	http://www.decebal.nl/
Cancel-Lock	sha1:2BGn1SsbbEb8oXLwh5hm0gJhMr8= sha1:1nlA9vyPwTpWTEEEY+eBailBZFo=
Xref	csiph.com comp.lang.java.programmer:32934

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Saturday 24 Oct 2015 00:51 CEST, Cecil Westerhof wrote:

> On Friday 23 Oct 2015 18:12 CEST, Tassilo Horn wrote:
>
>> Cecil Westerhof <Cecil@decebal.nl> writes:
>>
>>> When I in class A change a field from class B in the clone, the
>>> field in the original is also changed. That should not happen.
>>>
>>> public class A implements Cloneable {
>>> 	private B key;
>>> ^^^
>>> 	public Object clone() throws CloneNotSupportedException {
>>> 		A clone  = (A) super.clone();
>>> 		B newKey = new B();
>>> B oldKey = getKey();
>>>
>>> 		newKey.setA(oldKey.getA());
>>> 		newKey.setB(oldKey.getB());
>>> 		newKey.setC(oldKey.getC());
>>> 		newKey.setD(oldKey.getD());
>>> 		clone.setKey(key);
>> ^^^
>>
>> I guess here you want to set the key of the clone to newKey, not to
>> this.key.
>
> Was an error in my dumbing down. :'-( In the original program it was
> done correctly.
>
>
> I found the problem. It is an application where the class is a JPA
> class. When doing the test (in the original program) with an entity
> that was gotten by a read it goes wrong. When doing it with an
> entity gotten by a new it does what I expect.
>
> Maybe it has to do with the fact that key is the primary key?

For if someone is interested. I rewrote the code. I made the class B
Cloneable again. (Was like this before my first post, but I was
thinking that maybe there went something wrong.) When class B changes
class A does not need to change. Also added hashCode to toString.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

What goes wrong with cloning here Cecil Westerhof <Cecil@decebal.nl> - 2015-10-23 17:49 +0200
  Re: What goes wrong with cloning here Tassilo Horn <tsdh@gnu.org> - 2015-10-23 18:12 +0200
    Re: What goes wrong with cloning here Cecil Westerhof <Cecil@decebal.nl> - 2015-10-24 00:51 +0200
      Re: What goes wrong with cloning here Cecil Westerhof <Cecil@decebal.nl> - 2015-10-24 01:44 +0200

csiph-web