On 4 June 2013 18:37, Phil Harvey <[email protected]> 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 <[email protected]> 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 hand). 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
