On 19/03/2009, Paul Benedict <pbened...@apache.org> wrote: > 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.
OK. AFAIK, the JCIP annotations are the original ones for concurrency issues. And they are available with a Create Commons license. > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
