He didn't create his own hash function, he generated it in eclipse. This is
better because you get all the testing of other eclipse users without any
runtime dependencies.
On 6 February 2015 at 16:16, William Speirs <wspe...@apache.org> wrote:
> I'm not sure I understand your comment Mat. From what I can tell, Michael
> made his own hash function. That's fine, but *might* have unexpected
> collision issues. Might not too... I don't know. My guess though is that
> he's not an expert (who is an expert on hash functions?) and might
> unknowingly fall into a trap here.
>
> For example, commons-lang HashBuilder uses 37 as the "prime" and 17 as the
> initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
> risk it? Why not just use the library and not reinvent the wheel? (Most
> valid reason would be not wanting to pull in a whole library for these two
> functions/classes.)
>
> Again, take my advice for what you paid, nothing. :-)
>
> Bill-
>
> On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard <matt...@jaggard.org.uk>
> wrote:
>
> > William - I'm not sure if you noticed, but they didn't hand-make
> anything.
> >
> > On 6 February 2015 at 16:00, William Speirs <wspe...@apache.org> wrote:
> >
> > > 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
> > > >
> > > >
> > >
> >
>
