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 17:04:22 GMT
On 4 June 2013 18:54, Rajith Attapattu <rajith77@gmail.com> wrote:

> I'm strongly against using dependencies for the JMS client unless it's
> unavoidable.
> We can make exception for slf4j, but even then my preference is to use JDK
> logging.
>

If only JDK logging weren't so horrible :-)



> We've had several issues dealing with dependencies in the past.
>
> Increasingly our client is being used in various containers like
> AppServers, ESB's etc.. and mismatched libraries have caused issues.
> If I put my rpm-packager hat on, then not having dependencies is a huge
> bonus.
>
> One of the explicit goals of proton was to keep the dependencies to a
> minimum (if not eliminate it completely).
> I think we should extend that goal for the JMS client as well.
>
>
Agreed.  Maybe this is something we should add to the coding standards :-)

-- Rob


> Having a compact, dependency free library is always a plus point.
>
> Rajith
>
>
> On Tue, Jun 4, 2013 at 12:46 PM, Rob Godfrey <rob.j.godfrey@gmail.com
> >wrote:
>
> > 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
> > 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
> >
>

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