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 17:58:45 GMT
On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

> 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 :-)
>

Agreed, hence my reason to make an exception for slf4j :D

>
>
>
> > 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 :-)
>

+1

>
> -- 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