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 <seb...@gmail.com> wrote: > On 19/03/2009, Paul Benedict <pbened...@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 <seb...@gmail.com> wrote: >> > On 19/03/2009, Stephen Colebourne <scolebou...@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-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
