qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Tue, 04 Jun 2013 16:46:56 GMT
On 4 June 2013 18:37, Phil Harvey <phil@philharveyonline.com> wrote:

> Ah, I expected a swift response about this.  Luckily I'd already donned my
> tin hat :-)
> On 4 June 2013 17:16, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:
> > I'm not really a big fan of enforcing commons lang for toString  -
> > sometimes you want/need to have a specific string representation of an
> > object.
> Indeed - that's why I wrote "should" rather than "must".  I accept that
> there are exceptional cases but believe there's a benefit in the other 90%
> of classes doing things in the same way as each other.
> For clarity I will add the usual "should vs must" distinction at the top of
> the wiki page.
> >  Similarly I think we should be intelligent in defining equals and
> > hashCode() methods.
> >
> > What I'd actually prefer to say is that every object should define a
> > toString().
> >
> Yep, that's in the main coding standards already.
> >
> > In general I'd like to avoid having dependence on external libraries
> unless
> > we *really* need to.
> >
> You presumably believe that the use of EqualsBuilder and HashCodeBuilder
> for faciliating the bug-free implementation of equals() and hashCode() does
> not merit the inclusion of commons-lang as a dependency?

They are tools but, to be honest, my IDE will build correct equals and
hashCode methods for me (and toString as well) whereas it wouldn't generate
code which used commons lang in this way, so it'd be adding work for me and
likely increasing the likelihood of my making an error (what with the IDE
being automated and all, versus having to code the commans lang approach by

So... no I don't think it merits adding a dependency to the JMS client.
Adding any library as a dependency for the client is a big deal because it
introduces the possibility of a dependency clash with the application the
library is being used by.  SLF4J is specifically designed for this case and
is perhaps the only library I'd feel comfortable depending on.  Everything
else would need a much stronger justification in my book :-)

-- Rob

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message