You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Phil Harvey <ph...@philharveyonline.com> on 2013/06/04 17:55:33 UTC
AMQP 1.0 JMS client - supplementary coding standards
Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
slate, this is an opportunity to define some Java coding standards that are
somewhat tighter than our existing ones [1]. I've therefore created a wiki
page for supplementary standards [2] that only apply to this project.
I realise I am laying myself open to accusations of being overly
prescriptive. However, I find it easier to work with a codebase if
standard things like logging, toString, TODO comments etc are always done
in the same way (unless there's exceptional circumstances).
If you're interested in this topic I recommend that you use Confluence's
"watch page" feature to keep track of further updates.
Comments welcomed.
Phil
[1] https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
[2]
https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rob Godfrey <ro...@gmail.com>.
On 5 June 2013 13:00, Rafael Schloming <rh...@alum.mit.edu> wrote:
> On the logging topic I think the JMS client (or any project really) should
> actually have an internal logging interface that wraps what it actually
> uses for logging. I've done this in the past a lot and found it very useful
> for a number of reasons. For one thing the internal interface can actually
> reflect and enforce the logging categories that are specific to the project
> and also introduce a granularity of domain specific control that might not
> be available through generic loggers, e.g. toggling per connection, etc.
> This also has the significant benefit that any external logging dependency
> is limited to a single place in the code and therefore trivial to swap out
> with JDK logging or a println or whatever logging library you want.
>
>
I agree, there's really a couple of things wrong with the way most Java
libraries do logging... Firstly they tend to confuse operational logging
with debug/tracing statements that are useful for developers. Examples in
log4j and java.logging where the logging "channel" used is the class name
have encouraged this practice, but this seems entirely inappropriate to
me. Logging intended for the end user is essentially part of the public
API of your library/application. By tieing the logging to the
class/package hierarchy you are essentially setting that organization in
stone. Even if that is not objectionable to you, it seems entirely
inappropriate to expect the end user to understand the static properties of
your library/application in order to get useful operational logging about
the dynamic properties of the running system. This is my second big issue
with logging in the way that it is currently done... loggers tend to be
instantiated as static for a given class meaning that (to illustrate Rafi's
example) if you want to turn on detailed logging for a particular
connection you actually have to turn on logging for *all* connections and
then work out which lines are actually of interest. This is particularly
annoying in libraries that may be widely used since more than one
dependency of your application may in turn depend on the same library.
> I think this approach is probably where we will end up going with proton
> with the further step of having the facade actually wrap a configurable
> logging callback so we don't need to build in any logging dependency at all
> and it becomes easy to integrate the engine's logging with the logging of
> its embedding application.
>
>
Yes - I would like to get that work started in Proton ASAP so that we can
build on it for the JMS client which uses Proton. As above, I think that
logging forms part of the Public API so ideally all implementations of the
Proton Engine should aim to generate logs in an identical (or near
identical) manner.
-- Rob
> --Rafael
>
>
>
> On Wed, Jun 5, 2013 at 5:53 AM, Robbie Gemmell <robbie.gemmell@gmail.com
> >wrote:
>
> > For TODOs, I usually just consider them all roughly equally (in that
> there
> > should be a comment saying what needs changed and why) without any
> special
> > classification. I tend to closely examine all my changes prior to commit
> so
> > if I mean to change something I have added a TODO for before commiting
> then
> > I probably would have, so I'm not sure I personally see much specific
> value
> > in TODO-SVN. For TODO-RELEASE, that seems like more of a JIRA thing for
> me;
> > either we think the JIRA being worked on isn't finished and would comment
> > on it to say there was something specific needing done to allow
> completing
> > it, or we think it is done but there is need of a new separate JIRA
> > blocking the release.
> >
> > I would tend to mostly echo the previous comments on the toString() etc
> > stuff.
> >
> > Robbie
> >
> > On 4 June 2013 16:55, Phil Harvey <ph...@philharveyonline.com> wrote:
> >
> > > Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> > > slate, this is an opportunity to define some Java coding standards that
> > are
> > > somewhat tighter than our existing ones [1]. I've therefore created a
> > wiki
> > > page for supplementary standards [2] that only apply to this project.
> > >
> > > I realise I am laying myself open to accusations of being overly
> > > prescriptive. However, I find it easier to work with a codebase if
> > > standard things like logging, toString, TODO comments etc are always
> done
> > > in the same way (unless there's exceptional circumstances).
> > >
> > > If you're interested in this topic I recommend that you use
> Confluence's
> > > "watch page" feature to keep track of further updates.
> > >
> > > Comments welcomed.
> > >
> > > Phil
> > >
> > > [1]
> > https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> > > [2]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
> > >
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Phil Harvey <ph...@philharveyonline.com>.
I don't think it's worth retaining any JMS Client coding standards so I've
removed the page.
I did however tweak the main coding standards [1] to briefly mention TODO
comments, made a couple of draconian rules "recommended" rather than
mandatory, and touched on documenting the thread-safety of classes.
[1] https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
On 5 June 2013 13:00, Gordon Sim <gs...@redhat.com> wrote:
> On 06/05/2013 12:00 PM, Rafael Schloming wrote:
>
>> I think this approach is probably where we will end up going with proton
>> with the further step of having the facade actually wrap a configurable
>> logging callback so we don't need to build in any logging dependency at
>> all
>> and it becomes easy to integrate the engine's logging with the logging of
>> its embedding application.
>>
>
> This would be hugely beneficial for the c++ brokers use of proton.
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Gordon Sim <gs...@redhat.com>.
On 06/05/2013 12:00 PM, Rafael Schloming wrote:
> I think this approach is probably where we will end up going with proton
> with the further step of having the facade actually wrap a configurable
> logging callback so we don't need to build in any logging dependency at all
> and it becomes easy to integrate the engine's logging with the logging of
> its embedding application.
This would be hugely beneficial for the c++ brokers use of proton.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On the logging topic I think the JMS client (or any project really) should
actually have an internal logging interface that wraps what it actually
uses for logging. I've done this in the past a lot and found it very useful
for a number of reasons. For one thing the internal interface can actually
reflect and enforce the logging categories that are specific to the project
and also introduce a granularity of domain specific control that might not
be available through generic loggers, e.g. toggling per connection, etc.
This also has the significant benefit that any external logging dependency
is limited to a single place in the code and therefore trivial to swap out
with JDK logging or a println or whatever logging library you want.
I think this approach is probably where we will end up going with proton
with the further step of having the facade actually wrap a configurable
logging callback so we don't need to build in any logging dependency at all
and it becomes easy to integrate the engine's logging with the logging of
its embedding application.
--Rafael
On Wed, Jun 5, 2013 at 5:53 AM, Robbie Gemmell <ro...@gmail.com>wrote:
> For TODOs, I usually just consider them all roughly equally (in that there
> should be a comment saying what needs changed and why) without any special
> classification. I tend to closely examine all my changes prior to commit so
> if I mean to change something I have added a TODO for before commiting then
> I probably would have, so I'm not sure I personally see much specific value
> in TODO-SVN. For TODO-RELEASE, that seems like more of a JIRA thing for me;
> either we think the JIRA being worked on isn't finished and would comment
> on it to say there was something specific needing done to allow completing
> it, or we think it is done but there is need of a new separate JIRA
> blocking the release.
>
> I would tend to mostly echo the previous comments on the toString() etc
> stuff.
>
> Robbie
>
> On 4 June 2013 16:55, Phil Harvey <ph...@philharveyonline.com> wrote:
>
> > Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> > slate, this is an opportunity to define some Java coding standards that
> are
> > somewhat tighter than our existing ones [1]. I've therefore created a
> wiki
> > page for supplementary standards [2] that only apply to this project.
> >
> > I realise I am laying myself open to accusations of being overly
> > prescriptive. However, I find it easier to work with a codebase if
> > standard things like logging, toString, TODO comments etc are always done
> > in the same way (unless there's exceptional circumstances).
> >
> > If you're interested in this topic I recommend that you use Confluence's
> > "watch page" feature to keep track of further updates.
> >
> > Comments welcomed.
> >
> > Phil
> >
> > [1]
> https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Robbie Gemmell <ro...@gmail.com>.
For TODOs, I usually just consider them all roughly equally (in that there
should be a comment saying what needs changed and why) without any special
classification. I tend to closely examine all my changes prior to commit so
if I mean to change something I have added a TODO for before commiting then
I probably would have, so I'm not sure I personally see much specific value
in TODO-SVN. For TODO-RELEASE, that seems like more of a JIRA thing for me;
either we think the JIRA being worked on isn't finished and would comment
on it to say there was something specific needing done to allow completing
it, or we think it is done but there is need of a new separate JIRA
blocking the release.
I would tend to mostly echo the previous comments on the toString() etc
stuff.
Robbie
On 4 June 2013 16:55, Phil Harvey <ph...@philharveyonline.com> wrote:
> Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> slate, this is an opportunity to define some Java coding standards that are
> somewhat tighter than our existing ones [1]. I've therefore created a wiki
> page for supplementary standards [2] that only apply to this project.
>
> I realise I am laying myself open to accusations of being overly
> prescriptive. However, I find it easier to work with a codebase if
> standard things like logging, toString, TODO comments etc are always done
> in the same way (unless there's exceptional circumstances).
>
> If you're interested in this topic I recommend that you use Confluence's
> "watch page" feature to keep track of further updates.
>
> Comments welcomed.
>
> Phil
>
> [1] https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> [2]
>
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Tue, Jun 4, 2013 at 1:58 PM, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey <ro...@gmail.com> wrote:
>
>> On 4 June 2013 18:54, Rajith Attapattu <ra...@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
The ActiveMQ JMS client depends on slf4j and we have not had user
complains about it.
--
Hiram Chirino
Engineering | Red Hat, Inc.
hchirino@redhat.com | fusesource.com | redhat.com
skype: hiramchirino | twitter: @hiramchirino
blog: Hiram Chirino's Bit Mojo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Phil Harvey <ph...@philharveyonline.com>.
Thanks for the responses. I hadn't appreciated the strength of feeling
against using external dependencies.
I disagree that using the commons-lang helper classes would yield code
that's more likely to contain errors, and also believe they yield more
readable code than the auto-generated version. Nevertheless, whatever your
view of their usefulness, I agree they are not essential so will remove
them from the wiki page.
I'll add the general policy on external dependencies to the design page
[1], and suggest we resolve the logging questions in a separate thread.
If we do come across more external libraries that have a stronger case for
inclusion (e.g. an I/O library), can I assume tools like jarjar [2] have
already been examined and dismissed?
Also, any views on the stuff I wrote on the wiki page about TODO comments?
*adjusts tin hat*
[1]
https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Requirements+and+Design
[2] https://code.google.com/p/jarjar/
On 4 June 2013 18:58, Rajith Attapattu <ra...@gmail.com> wrote:
> On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey <ro...@gmail.com>
> wrote:
>
> > On 4 June 2013 18:54, Rajith Attapattu <ra...@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 <ph...@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 <ro...@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
> > > >
> > >
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Jun 4, 2013 at 1:04 PM, Rob Godfrey <ro...@gmail.com> wrote:
> On 4 June 2013 18:54, Rajith Attapattu <ra...@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 <ph...@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 <ro...@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
> > >
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rob Godfrey <ro...@gmail.com>.
On 4 June 2013 18:54, Rajith Attapattu <ra...@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 <ph...@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 <ro...@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
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <ro...@gmail.com>wrote:
> On 4 June 2013 18:37, Phil Harvey <ph...@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 <ro...@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
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rob Godfrey <ro...@gmail.com>.
On 4 June 2013 18:37, Phil Harvey <ph...@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 <ro...@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
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Phil Harvey <ph...@philharveyonline.com>.
Ah, I expected a swift response about this. Luckily I'd already donned my
tin hat :-)
On 4 June 2013 17:16, Rob Godfrey <ro...@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?
>
> On slf4j for logging... I think we should work out what we're going to do
> with logging in proton and then see if we want to adopt the same approach.
>
OK let's do that soon. The longer we continue without a proper logging
approach the harder it will be to introduce one.
>
> -- Rob
>
>
> On 4 June 2013 17:55, Phil Harvey <ph...@philharveyonline.com> wrote:
>
> > Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> > slate, this is an opportunity to define some Java coding standards that
> are
> > somewhat tighter than our existing ones [1]. I've therefore created a
> wiki
> > page for supplementary standards [2] that only apply to this project.
> >
> > I realise I am laying myself open to accusations of being overly
> > prescriptive. However, I find it easier to work with a codebase if
> > standard things like logging, toString, TODO comments etc are always done
> > in the same way (unless there's exceptional circumstances).
> >
> > If you're interested in this topic I recommend that you use Confluence's
> > "watch page" feature to keep track of further updates.
> >
> > Comments welcomed.
> >
> > Phil
> >
> > [1]
> https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
> >
>
Re: AMQP 1.0 JMS client - supplementary coding standards
Posted by Rob Godfrey <ro...@gmail.com>.
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. 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().
In general I'd like to avoid having dependence on external libraries unless
we *really* need to.
On slf4j for logging... I think we should work out what we're going to do
with logging in proton and then see if we want to adopt the same approach.
-- Rob
On 4 June 2013 17:55, Phil Harvey <ph...@philharveyonline.com> wrote:
> Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> slate, this is an opportunity to define some Java coding standards that are
> somewhat tighter than our existing ones [1]. I've therefore created a wiki
> page for supplementary standards [2] that only apply to this project.
>
> I realise I am laying myself open to accusations of being overly
> prescriptive. However, I find it easier to work with a codebase if
> standard things like logging, toString, TODO comments etc are always done
> in the same way (unless there's exceptional circumstances).
>
> If you're interested in this topic I recommend that you use Confluence's
> "watch page" feature to keep track of further updates.
>
> Comments welcomed.
>
> Phil
>
> [1] https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> [2]
>
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
>