Re: JSR311: Issue 39: Should NewCookie subclass Cookie

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 17 Jun 2008 15:12:20 -0400

On Jun 17, 2008, at 2:59 PM, Stephan Koops wrote:
> But IMO this class should get the methods hashCode() and equals(.).
> The logic requires, that (nc = aNewCookie, c = aCookie) if (nc1 == c
> && c == nc2) than MUST nc1 == nc2
> But the equality of nc and c could only be checked about the values
> of the attributes of Cookie. From this follows, that a Cookie must
> not be equal to a NewCookie. So there must taken care. One
> possibility is to add a second equals method with an addition
> parameter which says, if a Cookie could be equal to a NewCookie,
> where the default is false.
Agree that a NewCookie should never be equal to a Cookie.

Perhaps we should add a method to NewCookie that will get a Cookie
that could be used for comparison. E.g.:

Cookie c = ...
NewCookie nc = new NewCookie(c);
assertEquals(nc.getCookie(), c);

Not sure how much use this would really be though. Anyone have a good
use case for comparing a Cookie to a NewCookie ?

> Another possibility is to say, that this would not happen and ignore
> it, but that's not good IMO. Marc, if I should implement it, let me
> know.
Thanks for the offer but no need - NetBeans will generate a nice
implementation of equals and hashcode that will likely require very
little tweaking.


> Marc Hadley schrieb:
>> "While they share a number of attributes, Cookie and NewCookie
>> serve different purposes. It might be cleaner if NewCookie
>> contained a Cookie rather than inheriting from it."
>> From Stephan:
>> "Issue 39: if NewCookie should not subclass Cookie for design
>> reasons, then NewCookie could contain the same 5 attributes and
>> it's getter. I see no advantage that NewCookie has a Cookie as
>> attribute. Another possibility is a common subclass with the
>> attributes of Cookie, or a common interface. The first reduces the
>> lines of code, and both allows to handle a NewCookie and a Cookie
>> together, if someone needs it. For equals(.) a NewCookie must never
>> be equal to a Cookie, also if all values are the same, because noth
>> classes have a little bit different semantics. Perhaps we could add
>> an equal method If there is a common abstract class, their could be
>> a method AbstractCookie.equals(Cookie, boolean), which boolean
>> parameter allows to indicate, if a Cookie could be equal to a
>> NewCookie or not."
>> I'm tempted to close this one with no action (i.e. leave it as
>> NewCookie extends Cookie) - anyone have a strong opinion to the
>> contrary ?
>> Marc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Marc Hadley <marc.hadley at>
CTO Office, Sun Microsystems.