qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Tue, 04 Jun 2013 16:54:48 GMT
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.
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.

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