Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » EcoreUtil.copy and String attributes
EcoreUtil.copy and String attributes [message #689379] Mon, 27 June 2011 14:35 Go to next message
Pete Ellis is currently offline Pete EllisFriend
Messages: 85
Registered: July 2009
Member
Hello all,

A quick one: EcoreUtil.copy wants to invoke hashCode() on items that it is
copying. This seems to exception out, however, in the case where a String
attribute of the object to copy is "null". The auto generated code in my
xyzImpl class looks like:

public int hashCode() {
return getValue().hashCode();
}

where getValue() returns the String attribute "value".

Any way around this? Should the code that is automatically generated for
the hashCode() method concern itself with the possibility of null values?
Or should I work on my end to ensure that String attributes (or any
attribute for that matter, it would seem) are never null?

Thanks for any feedback on this,

-Pete

FYI: Using EMF 2.5 on Eclipse 3.5.1
Re: EcoreUtil.copy and String attributes [message #689446 is a reply to message #689379] Mon, 27 June 2011 16:22 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30450
Registered: July 2009
Senior Member
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pete,<br>
<br>
You've ignored this Javadoc for EObject<br>
<blockquote>&nbsp;* The framework also assumes that implementations will
not specialize {@link #equals(Object)} (nor {@link #hashCode()})<br>
&nbsp;* so that "&lt;code&gt;==&lt;/code&gt;" can be always used for
equality testing;<br>
&nbsp;* {@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing structural
equality testing.<br>
</blockquote>
More comments below.<br>
<br>
<br>
On 27/06/2011 7:35 AM, Pete Ellis wrote:
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">Hello
all,
<br>
<br>
A quick one:&nbsp; EcoreUtil.copy wants to invoke hashCode() on items
that it is copying.&nbsp; This seems to exception out, however, in the
case where a String attribute of the object to copy is "null".&nbsp;
The auto generated code in my xyzImpl class looks like:
<br>
<br>
public int hashCode() {
<br>
&nbsp;return getValue().hashCode();
<br>
}
<br>
<br>
where getValue() returns the String attribute "value".
<br>
</blockquote>
You've specialized equals as well?&nbsp; And you've carefully defined
equals and hashCode in Xyz interface?&nbsp; Nothing is allowed to extend
Xyz?&nbsp; You've ensured that such extensions won't end up producing an
asymmetric result for equality testing?<br>
<br>
As an example of the lengths you must go through to define these
properly, look at java.util.List's definitions of equals and
hashCode; note they even go so far as specifying the exact algorithm
that must be used for computing the hash code.&nbsp; Consider how it's
different from java.util.Set and consider how java.util.Collection
doesn't define it at all (so a Set can never be equal to a List nor
vice versa).<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">
<br>
Any way around this?&nbsp; Should the code that is automatically
generated for the hashCode() method concern itself with the
possibility of null values?</blockquote>
We don't automatically generate code for hashCode and absolutely
such code must produce a result for all possible cases.<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite"> Or
should I work on my end to ensure that String attributes (or any
attribute for that matter, it would seem) are never null?
<br>
</blockquote>
Don't do it.<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">
<br>
Thanks for any feedback on this,
<br>
<br>
-Pete
<br>
<br>
FYI:&nbsp; Using EMF 2.5 on Eclipse 3.5.1 <br>
</blockquote>
</body>
</html>
Re: EcoreUtil.copy and String attributes [message #689489 is a reply to message #689446] Mon, 27 June 2011 17:44 Go to previous messageGo to next message
Pete Ellis is currently offline Pete EllisFriend
Messages: 85
Registered: July 2009
Member
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type></HEAD>
<BODY dir=ltr bgColor=#ffffff text=#000000>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>Good grief; overriding implementations for both hashCode() and equals()
were inserted by another developer on our team; my apologies.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks for the pointer to EcoreUtil.equals() – that should answer the call
for us.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-Pete</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV
style="BORDER-BOTTOM-COLOR: #000000; BORDER-LEFT: #000000 4px solid; BORDER-TOP-COLOR: #000000; PADDING-LEFT: 5px; BORDER-RIGHT-COLOR: #000000; MARGIN-LEFT: 5px">
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<DIV>"Ed Merks" &lt;Ed.Merks@gmail.com&gt; wrote in message
news:iuaa6h$uto$1@news.eclipse.org...</DIV></DIV></DIV>
<DIV
style="BORDER-BOTTOM-COLOR: #000000; BORDER-LEFT: #000000 4px solid; BORDER-TOP-COLOR: #000000; PADDING-LEFT: 5px; BORDER-RIGHT-COLOR: #000000; MARGIN-LEFT: 5px">
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">Pete,<BR><BR>You've
ignored this Javadoc for EObject<BR>
<BLOCKQUOTE>* The framework also assumes that implementations will not
specialize {@link #equals(Object)} (nor {@link #hashCode()})<BR>* so that
"&lt;code&gt;==&lt;/code&gt;" can be always used for equality testing;<BR>*
{@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject, EObject)
EcoreUtil.equals} should be used for doing structural equality
testing.<BR></BLOCKQUOTE>More comments below.<BR><BR><BR>On 27/06/2011 7:35 AM,
Pete Ellis wrote:
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite">Hello all,
<BR><BR>A quick one:&nbsp; EcoreUtil.copy wants to invoke hashCode() on items
that it is copying.&nbsp; This seems to exception out, however, in the case
where a String attribute of the object to copy is "null".&nbsp; The auto
generated code in my xyzImpl class looks like: <BR><BR>public int hashCode() {
<BR>return getValue().hashCode(); <BR>} <BR><BR>where getValue() returns the
String attribute "value". <BR></BLOCKQUOTE>You've specialized equals as
well?&nbsp; And you've carefully defined equals and hashCode in Xyz
interface?&nbsp; Nothing is allowed to extend Xyz?&nbsp; You've ensured that
such extensions won't end up producing an asymmetric result for equality
testing?<BR><BR>As an example of the lengths you must go through to define these
properly, look at java.util.List's definitions of equals and hashCode; note they
even go so far as specifying the exact algorithm that must be used for computing
the hash code.&nbsp; Consider how it's different from java.util.Set and consider
how java.util.Collection doesn't define it at all (so a Set can never be equal
to a List nor vice versa).<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite"><BR>Any way
around this?&nbsp; Should the code that is automatically generated for the
hashCode() method concern itself with the possibility of null
values?</BLOCKQUOTE>We don't automatically generate code for hashCode and
absolutely such code must produce a result for all possible cases.<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite">Or should I
work on my end to ensure that String attributes (or any attribute for that
matter, it would seem) are never null? <BR></BLOCKQUOTE>Don't do it.<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite"><BR>Thanks for
any feedback on this, <BR><BR>-Pete <BR><BR>FYI:&nbsp; Using EMF 2.5 on
Eclipse 3.5.1 <BR></BLOCKQUOTE></DIV></DIV></DIV></DIV></BODY></HTML>
EObject == Javadoc; was EcoreUtil.copy and String attributes [message #689509 is a reply to message #689446] Mon, 27 June 2011 18:30 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6457
Registered: July 2009
Senior Member
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Ed<br>
<br>
I must be being very stupid, but I don't understand the comment.<br>
<blockquote cite="mid:iuaa6h$uto$1@news.eclipse.org" type="cite">
You've ignored this Javadoc for EObject<br>
<blockquote>&nbsp;* The framework also assumes that implementations
will not specialize {@link #equals(Object)} (nor {@link
#hashCode()})<br>
&nbsp;* so that "&lt;code&gt;==&lt;/code&gt;" can be always used for
equality testing;<br>
&nbsp;* {@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing structural
equality testing.<br>
</blockquote>
</blockquote>
Surely how "==" is used for equality testing is unaffected by
equals(Object) overloads?<br>
<br>
Is there a stronger coherence requirement than Java's a.hashCode()
!= b.hashCode() implies !a.equals(b)?<br>
<br>
I did a quick experiment and put final versions of equals and
hashCode in EObjectImpl; 3 pairs of errors from MDT/OCL. Two in test
classes, but one in a private static class in the main code
supporting Tuples that are a kind of dynamic class. The
implementations of equals and hashCode are non-trivial, so hopefully
carefully coded and so complying with the Java constraint but not
the EObject constraint. Should I be raising a Bugzilla on OCL for
violating the EObject Javadoc or on EMF Core for an inappropriate
EObject Javadoc?<br>
<br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink<br>
</body>
</html>
Re: EObject == Javadoc; was EcoreUtil.copy and String attributes [message #689530 is a reply to message #689509] Mon, 27 June 2011 18:50 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30450
Registered: July 2009
Senior Member
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
Comments below.<br>
<br>
On 27/06/2011 11:30 AM, Ed Willink wrote:
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Ed<br>
<br>
I must be being very stupid, but I don't understand the comment.<br>
<blockquote cite="mid:iuaa6h$uto$1@news.eclipse.org" type="cite">
You've ignored this Javadoc for EObject<br>
<blockquote>&nbsp;* The framework also assumes that implementations
will not specialize {@link #equals(Object)} (nor {@link
#hashCode()})<br>
&nbsp;* so that "&lt;code&gt;==&lt;/code&gt;" can be always used
for equality testing;<br>
&nbsp;* {@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing structural
equality testing.<br>
</blockquote>
</blockquote>
Surely how "==" is used for equality testing is unaffected by
equals(Object) overloads?<br>
</blockquote>
No, the point is that the framework assumes that the implementation
not override equals for hashCode&nbsp; so just as for java.lang.Object
instances a and b, (a == b) == (a == null ? b == null :
a.equals(b)).&nbsp; <br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
Is there a stronger coherence requirement than Java's a.hashCode()
!= b.hashCode() implies !a.equals(b)?<br>
</blockquote>
No, that's impossible to guarantee for almost any not trivial class.<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
I did a quick experiment and put final versions of equals and
hashCode in EObjectImpl; 3 pairs of errors from MDT/OCL.</blockquote>
Yes not everyone follows the advice.<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite">
Two in test classes, but one in a private static class in the main
code supporting Tuples that are a kind of dynamic class. The
implementations of equals and hashCode are non-trivial, so
hopefully carefully coded and so complying with the Java
constraint but not the EObject constraint. Should I be raising a
Bugzilla on OCL for violating the EObject Javadoc or on EMF Core
for an inappropriate EObject Javadoc?<br>
</blockquote>
I don't demand (or enforce) that everyone follow the advice.&nbsp; I&nbsp;
just explain what people should do and then let them do whatever
they want at their own risk.&nbsp; Perhaps they have a good reason to
ignore the advice and are willing to live the with consequences...<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed Willink<br>
</blockquote>
</body>
</html>
Re: EObject == Javadoc; was EcoreUtil.copy and String attributes [message #689560 is a reply to message #689530] Mon, 27 June 2011 19:37 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6457
Registered: July 2009
Senior Member
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Ed<br>
<blockquote cite="mid:iuais2$8an$1@news.eclipse.org" type="cite">
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite">
<blockquote cite="mid:iuaa6h$uto$1@news.eclipse.org" type="cite">
You've ignored this Javadoc for EObject<br>
<blockquote>&nbsp;* The framework also assumes that implementations
will not specialize {@link #equals(Object)} (nor {@link
#hashCode()})<br>
&nbsp;* so that "&lt;code&gt;==&lt;/code&gt;" can be always used
for equality testing;<br>
&nbsp;* {@link
org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing
structural equality testing.<br>
</blockquote>
</blockquote>
Surely how "==" is used for equality testing is unaffected by
equals(Object) overloads?<br>
</blockquote>
No, the point is that the framework assumes that the
implementation not override equals for hashCode&nbsp; so just as for
java.lang.Object instances a and b, (a == b) == (a == null ? b ==
null : a.equals(b)).&nbsp; <br>
</blockquote>
Ok. Suggest<br>
<br>
* ...<br>
* in a way that invalidates the use of "&lt;code&gt;==&lt;/code&gt;"
rather than {@link #equals(Object)} for equality testing;<br>
<br>
which avoids the statement of the obvious that confused me, and
indicates the responsibilities that anyone brave enough to
specialize must address. In the light of that understanding, I must
now raise a bug against the mature OCL code. I can't really imagine
an implementation of equals()&nbsp; other than one with debug logging
that can do much while meeting the "same as ==" behaviour
requirement.<br>
<br>
&nbsp;&nbsp;&nbsp; Regards<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Ed<br>
<br>
<br>
<br>
</body>
</html>
Previous Topic:[CDO] Retrieve EstructuralFeature corresponding to InternalCDORevision#getContainingFeatureId()
Next Topic:Serialization Option
Goto Forum:
  


Current Time: Wed Sep 18 21:42:48 GMT 2019

Powered by FUDForum. Page generated in 0.02188 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top