commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
Subject Re: [LANG] 3.0 JCIP Annotations
Date Thu, 19 Mar 2009 12:36:55 GMT
sebb,

I must have mis-stated my point. If Commons Lang uses JCIP @Immutable
annotations, and another Commons project uses a theoretical XYZ
@NotMutable annotations, we will have lost the ability to track bugs
across project boundaries. So my point was that we should all agree
that using JCIP -- if you want to use them -- is the canonical
bug-detecting annotations for any Commons project. Let's just avoid
duplication.

Paul

On Thu, Mar 19, 2009 at 6:07 AM, sebb <sebbaz@gmail.com> wrote:
> On 19/03/2009, Paul Benedict <pbenedict@apache.org> wrote:
>> I think the use of JCIP annotations should be an Apache Commons-wide
>>  decision. It would only be sensible to share the annotations across
>>  projects. Otherwise, we could get fragmentation pretty easily.
>
> Fragmentation?
>
> If a project uses concurrency annotations, it should use the same
> library, buy I see no reason why every component should _have_ to use
> them.
>
>>
>>  Paul
>>
>>
>>  On Wed, Mar 18, 2009 at 9:48 PM, sebb <sebbaz@gmail.com> wrote:
>>  > On 19/03/2009, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
>>  >> sebb wrote:
>>  >>
>>  >> >
>>  >> > >  Are you proposing including these pieces of annotation code
in [lang],
>>  >> or
>>  >> > > just referencing them? If its just referencing them, then it
has no real
>>  >> > > effect, and should be fine (aprt from making the compilation
a little
>>  >> more
>>  >> > > complex)
>>  >> > >
>>  >> > >
>>  >> >
>>  >> > I'm not sure what you mean by "including" or "referencing".
>>  >> >
>>  >> > I am proposing to add
>>  >> >
>>  >> > import net.jcip.annotations.Immutable
>>  >> > and
>>  >> > @Immutable
>>  >> >
>>  >> > to the source files of classes that deserve it. Similarly for the
other
>>  >> cases.
>>  >> >
>>  >> > Much like using @Override, except that the annotations are not part
of the
>>  >> JDK.
>>  >> >
>>  >>
>>  >>  Thats OK technically (as there is no runtime dependency on
>>  >> net.jcip.annotations). However, I suspect it will confuse users, as very
few
>>  >> people realise that no dependency is created beyond compilation time.
>>  >>
>>  >>  So, overall, I'm dubious as to whether the value is sufficient to
>>  >> compilcate the compliation and to field the inevitable confusion/questions
>>  >> as to 'why we added a dependency' (when we didn't add one really...)
>>  >>
>>  >
>>  > Again, I'm not sure I follow.
>>  >
>>  > I don't see how the addition of a single new dependency complicates
>>  > the compilation.
>>  > If there is any complication, it is from trying to follow what Maven
>>  > is doing ;-).
>>  >
>>  > Nor do I see why users will be confused, so long as the site shows
>>  > that LANG depends on Java 1.5 only.  Many of them will just use Maven
>>  > to pick up the new version. If necessary one can always add some
>>  > information on the site as to how annotations behave.
>>  >
>>  > I think it's well worth the exercise of checking all the classes to
>>  > see which annotation applies; if necessary the annotations (and
>>  > imports) could be added as single-line comments. [But I really don't
>>  > want to do that.]
>>  >
>>  > I suspect that the change to using generics will be a much greater
>>  > challenge to users; if they can cope with that, then annotations
>>  > should be relatively easy.
>>  >
>>  > Indeed hopefully users will start adding annotations to their own code...
>>  >
>>  >>  Stephen
>>  >>
>>  >>
>>  >> ---------------------------------------------------------------------
>>  >>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  >>  For additional commands, e-mail: dev-help@commons.apache.org
>>  >>
>>  >>
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  > For additional commands, e-mail: dev-help@commons.apache.org
>>  >
>>  >
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message