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
