<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"	>
<channel>
	<title>Comments on: What you didn&#8217;t think you needed to know about hashCode and equals</title>
	<atom:link href="http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/feed/" rel="self" type="application/rss+xml" />
	<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/</link>
	<description>Johannes Brodwall&#039;s Musings on Software Architecture and Programming</description>
	<lastBuildDate>Thu, 29 Jul 2010 15:37:26 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Johannes Brodwall</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-127573</link>
		<dc:creator>Johannes Brodwall</dc:creator>
		<pubDate>Tue, 04 Nov 2008 12:00:39 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-127573</guid>
		<description>I&#039;ve never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I&#039;d run into other problems. FWIW, it sounds like your approach would behave correctly.</description>
		<content:encoded><![CDATA[<p>I&#39;ve never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I&#39;d run into other problems. FWIW, it sounds like your approach would behave correctly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jhannes</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-97948</link>
		<dc:creator>jhannes</dc:creator>
		<pubDate>Tue, 04 Nov 2008 04:00:39 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-97948</guid>
		<description>I&#039;ve never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I&#039;d run into other problems. FWIW, it sounds like your approach would behave correctly.</description>
		<content:encoded><![CDATA[<p>I&#39;ve never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I&#39;d run into other problems. FWIW, it sounds like your approach would behave correctly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jakob</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-97901</link>
		<dc:creator>jakob</dc:creator>
		<pubDate>Mon, 03 Nov 2008 09:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-97901</guid>
		<description>rzei raises a valid point regarding changing fields. What is your advice regarding the implementation of hashcode()? Is the only way to compute and persist some kind of unchangeable UID for each object?&lt;br&gt;&lt;br&gt;In a framework I have used, persistent keys were (wastefully) created with the object, so even if the object would never be persisted, it still had a PK. So one could use the PK in hashcode implementations.</description>
		<content:encoded><![CDATA[<p>rzei raises a valid point regarding changing fields. What is your advice regarding the implementation of hashcode()? Is the only way to compute and persist some kind of unchangeable UID for each object?</p>
<p>In a framework I have used, persistent keys were (wastefully) created with the object, so even if the object would never be persisted, it still had a PK. So one could use the PK in hashcode implementations.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomas</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-97900</link>
		<dc:creator>Tomas</dc:creator>
		<pubDate>Mon, 03 Nov 2008 09:02:17 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-97900</guid>
		<description>I agree that too few posts have been written on this subject. I&#039;ve come into problems with equals/hashCode and persistance serveral times, but I haven&#039;t found very much useful info on the topic.</description>
		<content:encoded><![CDATA[<p>I agree that too few posts have been written on this subject. I&#39;ve come into problems with equals/hashCode and persistance serveral times, but I haven&#39;t found very much useful info on the topic.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jhannes</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-97898</link>
		<dc:creator>jhannes</dc:creator>
		<pubDate>Mon, 03 Nov 2008 08:03:01 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-97898</guid>
		<description>Hi, rzei&lt;br&gt;&lt;br&gt;The example wasn&#039;t very clear. I&#039;ve run into the the problem in the following situations: I have a Parent object that includes many Children in a HashSet. I construct a new Parent and add Children to it, then I persist the Parent for the first time, and the HashSet is configured persisted as well, through cascading.&lt;br&gt;&lt;br&gt;The result is that the Child objects are given an id, their hashCode change, and I can no longer find them.&lt;br&gt;&lt;br&gt;Hope this was clearer?</description>
		<content:encoded><![CDATA[<p>Hi, rzei</p>
<p>The example wasn&#39;t very clear. I&#39;ve run into the the problem in the following situations: I have a Parent object that includes many Children in a HashSet. I construct a new Parent and add Children to it, then I persist the Parent for the first time, and the HashSet is configured persisted as well, through cascading.</p>
<p>The result is that the Child objects are given an id, their hashCode change, and I can no longer find them.</p>
<p>Hope this was clearer?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rzei</title>
		<link>http://johannesbrodwall.com/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/comment-page-1/#comment-97897</link>
		<dc:creator>rzei</dc:creator>
		<pubDate>Mon, 03 Nov 2008 07:26:12 +0000</pubDate>
		<guid isPermaLink="false">http://brodwall.com/johannes/blog/2008/11/02/what-you-didnt-think-you-needed-to-know-about-hashcode-and-equals/#comment-97897</guid>
		<description>From a Hibernate users standpoint, could you give an example of a situation where you need to store a hashset of objects of which some are persisted, some get persisted why stored in set and some do not?&lt;br&gt;&lt;br&gt;If you declare that id shouldn&#039;t be used in hashCode; in the same way you could say that you cannot use any fields in hashCode, as every one of those can change. &lt;br&gt;&lt;br&gt;Surrogate should be the most stable property of an persist entity as it changes only once.&lt;br&gt;&lt;br&gt;Great post though, too few have been written on the subject.</description>
		<content:encoded><![CDATA[<p>From a Hibernate users standpoint, could you give an example of a situation where you need to store a hashset of objects of which some are persisted, some get persisted why stored in set and some do not?</p>
<p>If you declare that id shouldn&#39;t be used in hashCode; in the same way you could say that you cannot use any fields in hashCode, as every one of those can change. </p>
<p>Surrogate should be the most stable property of an persist entity as it changes only once.</p>
<p>Great post though, too few have been written on the subject.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
