Why wouldn't you use the HashCodeBuilder? Much simpler:

return new HashCodeBuilder().append(internalId).toHashCode();

Done in 1 line, and probably fewer collisions than your hand-made one. Same
with the EqualsBuilder...

If you don't want the dep on commons-lang, then I can understand... but I'd
just borrow their internal algo.

My $0.02...

Bill-

On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov <1983-01...@gmx.net> wrote:

> This is what I did:
> this.internalId = RandomStringUtils.randomAlphanumeric(8);
>
> Some Eclipse magic:
> @Override
>         public int hashCode() {
>                 final int prime = 31;
>                 int result = 1;
>                 result = prime * result + ((internalId == null) ? 0 :
> internalId.hashCode());
>                 return result;
>         }
>
>         @Override
>         public boolean equals(Object obj) {
>                 if (this == obj)
>                         return true;
>                 if (obj == null)
>                         return false;
>                 if (getClass() != obj.getClass())
>                         return false;
>                 RawSession other = (RawSession) obj;
>                 if (internalId == null) {
>                         if (other.internalId != null)
>                                 return false;
>                 } else if (!internalId.equals(other.internalId))
>                         return false;
>                 return true;
>         }
>
> > Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
> > Von: "James Carman" <ja...@carmanconsulting.com>
> > An: "Commons Users List" <user@commons.apache.org>
> > Betreff: Re: [POOL2] Pooling mutable objects
> >
> > Or just let your IDE generate the methods.
> >
> >
> > On Fri, Feb 6, 2015 at 9:05 AM, William Speirs <wspe...@apache.org>
> wrote:
> > > I'd think adding a UUID then overriding equals and hashCode would do
> the
> > > trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
> > > HashCodeBuilder [2], I highly recommend using them.
> > >
> > > Bill-
> > >
> > >
> > > [1]
> > >
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
> > >
> > > [2]
> > >
> https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
> > >
> > > On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov <1983-01...@gmx.net>
> wrote:
> > >
> > >> Hi folks,
> > >>
> > >> I am developing a session pool for an HTTP backend which is requested
> with
> > >> the fabulous HttpClient.
> > >>
> > >> The session object is this:
> > >>
> > >> public class RawSession {
> > >>
> > >>         private CookieStore cookieStore;
> > >>         private String logId;
> > >>         private MutableInt requestId;
> > >>         private String clientId;
> > >>         private String serverId;
> > >>
> > >> }
> > >>
> > >> There won't be any setters but as you see, the cookie store and
> mutable
> > >> int might change.
> > >> Additionally, I did not implement any custom equals and hashCode
> methods.
> > >>
> > >> I have searched the docs and the found and did not find any clear
> answer
> > >> which says
> > >> that pooled objects have to be immutable. Though, I have found
> POOL-283
> > >> and POOL-284 which
> > >> led me to the conclusion that this is a problem because the objects
> are
> > >> stored in a map
> > >> which relies on equals and hashCode.
> > >>
> > >> Does this ultimately mean that I have to override equals and hashCode
> and
> > >> provide some internal,
> > >> immutable value something like a UUID? Alternatively, I could
> retrieve the
> > >> JSESSIONID from the
> > >> cookie store and use this as a unique value.
> > >>
> > >> Thanks,
> > >>
> > >> Michael
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: user-h...@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> > For additional commands, e-mail: user-h...@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
>
>

Reply via email to