Re: JSR311: Issue 39: Should NewCookie subclass Cookie

From: Stephan Koops <>
Date: Tue, 17 Jun 2008 20:59:34 +0200


IMO we could let it as it is

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.

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.

best regards

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.