You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2009/03/18 16:51:22 UTC
[LANG] 3.0 JCIP Annotations
I've added JCIP annotations jar to the POM, but not started adding any
actual annotations yet.
The idea would be to annotate every class as one of
@Immutable
@ThreadSafe
@NotThreadSafe
These annotation appear in the Javadoc output in the class description.
Also, for objects that need synchronization to ensure thread safety,
add the annotation
@GuardedBy
Are there any objections to proceeding with this?
It's probably easiest to deal with @Immutable first, then @ThreadSafe.
If no annotation is present, then the user _should_ assume that the
class is @NotThreadSafe, but I think it would be better to always have
an annotation so that it's clear it has not been accidentally left
off.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, Gary Gregory <GG...@seagullsoftware.com> wrote:
> > -----Original Message-----
> > From: sebb [mailto:sebbaz@gmail.com]
> > Sent: Friday, March 20, 2009 9:47 AM
> > To: Commons Developers List
> > Subject: Re: [LANG] 3.0 JCIP Annotations
> >
>
> > On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> > > On Fri, Mar 20, 2009 at 11:40 AM, sebb <se...@gmail.com> wrote:
> > > > It's only optional at run-time; it's not optional at compile-time.
> > > >
> > >
> > >
> > > Right. That's what optional means.
> >
> > I thought I understood optional, obviously I didn't.
> >
> > How does one express a dependency that really is optional at compile time?
> >
> > > Putting it as optional in Maven
> > > will change the dependencies report:
> > >
> > > http://commons.apache.org/proxy/dependencies.html
> >
> > I find the text on the report very confusing.
> >
> > Does (optional) mean "optional at compile and runtime" or "optional
> > for transitive dependencies"? Or something else?
> >
> > [BTW, JUnit should be updated to 3.8.2]
>
>
> Why not migrate to JUnit 4.5 since lang 3.0 is Java 5-based?
>
I think someone proposed TestNG for LANG...
However, my comment was directed at Proxy, which is targetted at Java 1.4+
> Gary
>
>
> >
> > Niall wrote that the use of optional caused problems for OSGI
> > dependencies, and I thought I saw that myself when I tried building
> > httpcore-osgi earlier - but now when I try that it works fine.
> >
> > My head is spinning!
> >
> > > None of the dependencies in Proxy (other than the JDK itself) are
> > > required. However, maven does put them on the classpath so that Proxy
> > > will compile. When a user declares a dependency on Proxy, they don't
> > > get all of that extra stuff automatically.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
RE: [LANG] 3.0 JCIP Annotations
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, March 20, 2009 9:47 AM
> To: Commons Developers List
> Subject: Re: [LANG] 3.0 JCIP Annotations
>
> On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> > On Fri, Mar 20, 2009 at 11:40 AM, sebb <se...@gmail.com> wrote:
> > > It's only optional at run-time; it's not optional at compile-time.
> > >
> >
> >
> > Right. That's what optional means.
>
> I thought I understood optional, obviously I didn't.
>
> How does one express a dependency that really is optional at compile time?
>
> > Putting it as optional in Maven
> > will change the dependencies report:
> >
> > http://commons.apache.org/proxy/dependencies.html
>
> I find the text on the report very confusing.
>
> Does (optional) mean "optional at compile and runtime" or "optional
> for transitive dependencies"? Or something else?
>
> [BTW, JUnit should be updated to 3.8.2]
Why not migrate to JUnit 4.5 since lang 3.0 is Java 5-based?
Gary
>
> Niall wrote that the use of optional caused problems for OSGI
> dependencies, and I thought I saw that myself when I tried building
> httpcore-osgi earlier - but now when I try that it works fine.
>
> My head is spinning!
>
> > None of the dependencies in Proxy (other than the JDK itself) are
> > required. However, maven does put them on the classpath so that Proxy
> > will compile. When a user declares a dependency on Proxy, they don't
> > get all of that extra stuff automatically.
> >
> >
> > ---------------------------------------------------------------------
> > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 12:47 PM, sebb <se...@gmail.com> wrote:
> I thought I understood optional, obviously I didn't.
>
> How does one express a dependency that really is optional at compile time?
This particular dependency isn't optional at compile time (not for
lang which would be using it in its source). It would be optional for
other projects that use lang of course (optional for compile time).
>
>> Putting it as optional in Maven
>> will change the dependencies report:
>>
>> http://commons.apache.org/proxy/dependencies.html
>
> I find the text on the report very confusing.
>
> Does (optional) mean "optional at compile and runtime" or "optional
> for transitive dependencies"? Or something else?
It means optional as in how maven considers stuff optional. Again, if
we don't like the view, perhaps we should just supply a patch to the
plugin's JIRA?
>
> [BTW, JUnit should be updated to 3.8.2]
If I remember, I'll try to upgrade it before the next release (which I
hope to do soon).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Fri, Mar 20, 2009 at 11:40 AM, sebb <se...@gmail.com> wrote:
> > It's only optional at run-time; it's not optional at compile-time.
> >
>
>
> Right. That's what optional means.
I thought I understood optional, obviously I didn't.
How does one express a dependency that really is optional at compile time?
> Putting it as optional in Maven
> will change the dependencies report:
>
> http://commons.apache.org/proxy/dependencies.html
I find the text on the report very confusing.
Does (optional) mean "optional at compile and runtime" or "optional
for transitive dependencies"? Or something else?
[BTW, JUnit should be updated to 3.8.2]
Niall wrote that the use of optional caused problems for OSGI
dependencies, and I thought I saw that myself when I tried building
httpcore-osgi earlier - but now when I try that it works fine.
My head is spinning!
> None of the dependencies in Proxy (other than the JDK itself) are
> required. However, maven does put them on the classpath so that Proxy
> will compile. When a user declares a dependency on Proxy, they don't
> get all of that extra stuff automatically.
>
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Jörg Schaible <jo...@gmx.de>.
James Carman wrote:
> On Fri, Mar 20, 2009 at 11:40 AM, sebb <se...@gmail.com> wrote:
>> It's only optional at run-time; it's not optional at compile-time.
>>
>
> Right. That's what optional means. Putting it as optional in Maven
> will change the dependencies report:
>
> http://commons.apache.org/proxy/dependencies.html
>
> None of the dependencies in Proxy (other than the JDK itself) are
> required. However, maven does put them on the classpath so that Proxy
> will compile. When a user declares a dependency on Proxy, they don't
> get all of that extra stuff automatically.
Set it to provided+optional :)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 11:40 AM, sebb <se...@gmail.com> wrote:
> It's only optional at run-time; it's not optional at compile-time.
>
Right. That's what optional means. Putting it as optional in Maven
will change the dependencies report:
http://commons.apache.org/proxy/dependencies.html
None of the dependencies in Proxy (other than the JDK itself) are
required. However, maven does put them on the classpath so that Proxy
will compile. When a user declares a dependency on Proxy, they don't
get all of that extra stuff automatically.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Fri, Mar 20, 2009 at 11:11 AM, sebb <se...@gmail.com> wrote:
> > See post from Niall - it causes problems with OSGI bundles.
> >
> > If anything, I see that as an abuse of optional, because it's not optional.
>
>
> But, it *is* optional, because the annotations are not required at
> runtime.
It's only optional at run-time; it's not optional at compile-time.
> Putting it in "provided" scope means that it's up to the
> users to make sure it is actually provided in the runtime environment
> (such as the servlet API or something). This would make users think
> they need to make sure it's there when they really don't.
I guess we need to see what Maven does with the "provided" scope, and
see if that is worse than its behaviour "compile+optional".
In the meantime, I've changed the scope to provided, but added a
comment to say the dependency is optional at run-time.
> The dependency is a compile-time (the default scope), optional dependency.
No, it's not optional at compile-time.
It seems neither compile+optional nor provided will satisfy everyone,
so maybe the JIRA issue I raised and closed needs to be resurrected:
http://jira.codehaus.org/browse/MNG-4097
Would you be willing to explain your concerns there?
[I'll re-open it if you cannot]
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 11:11 AM, sebb <se...@gmail.com> wrote:
> See post from Niall - it causes problems with OSGI bundles.
>
> If anything, I see that as an abuse of optional, because it's not optional.
But, it *is* optional, because the annotations are not required at
runtime. Putting it in "provided" scope means that it's up to the
users to make sure it is actually provided in the runtime environment
(such as the servlet API or something). This would make users think
they need to make sure it's there when they really don't. The
dependency is a compile-time (the default scope), optional dependency.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, sebb <se...@gmail.com> wrote:
> > My bad, sorry.
> >
> > The scope "provided" is what is required.
> >
> > I misunderstood the documentation to mean that the user had to provide
> > the jar at compile-time, however it only requires the user to provide
> > the jar at run-time.
> >
> > "provided" does cause Maven to check the repository at compile-time,
> > which should solve the Maven issues raised in the thread.
> >
> > I have now tried it (after I deleted jar from repo) and it all worked well.
> > Sorry for the noise.
> >
>
>
> What's wrong with just marking it as optional?
See post from Niall - it causes problems with OSGI bundles.
If anything, I see that as an abuse of optional, because it's not optional.
> This is an abuse of the "provided" scope, IMHO.
Why?
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 10:31 AM, sebb <se...@gmail.com> wrote:
> My bad, sorry.
>
> The scope "provided" is what is required.
>
> I misunderstood the documentation to mean that the user had to provide
> the jar at compile-time, however it only requires the user to provide
> the jar at run-time.
>
> "provided" does cause Maven to check the repository at compile-time,
> which should solve the Maven issues raised in the thread.
>
> I have now tried it (after I deleted jar from repo) and it all worked well.
> Sorry for the noise.
>
What's wrong with just marking it as optional? This is an abuse of
the "provided" scope, IMHO.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, Eric Bowman <eb...@boboco.ie> wrote:
> sebb wrote:
>
> > On 20/03/2009, Paul Benedict <pb...@apache.org> wrote:
> >
> >
> > > The Maven folks verified that putting a dependency in
> > > <scope>provided</scope> will not create a runtime dependency. This
> > > should equal a compile-only scope.
> > >
> > >
> >
> > The problem with that is that the developer has to provide the
> > annotation jar in order to run the compile. This is an extra stage.
> > I'm not sure what it involves.
> >
> > If we can find a method to automate the provision process within the
> > Maven build, then that would work. Otherwise, we are just making it
> > awkward for developers.
> >
> >
> >
>
> This seems like a missing piece in maven. There should be a scope that
> covers exactly this case, like "compileNotRuntime" or something like that.
>
My bad, sorry.
The scope "provided" is what is required.
I misunderstood the documentation to mean that the user had to provide
the jar at compile-time, however it only requires the user to provide
the jar at run-time.
"provided" does cause Maven to check the repository at compile-time,
which should solve the Maven issues raised in the thread.
I have now tried it (after I deleted jar from repo) and it all worked well.
Sorry for the noise.
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Eric Bowman <eb...@boboco.ie>.
sebb wrote:
> On 20/03/2009, Paul Benedict <pb...@apache.org> wrote:
>
>> The Maven folks verified that putting a dependency in
>> <scope>provided</scope> will not create a runtime dependency. This
>> should equal a compile-only scope.
>>
>
> The problem with that is that the developer has to provide the
> annotation jar in order to run the compile. This is an extra stage.
> I'm not sure what it involves.
>
> If we can find a method to automate the provision process within the
> Maven build, then that would work. Otherwise, we are just making it
> awkward for developers.
>
>
This seems like a missing piece in maven. There should be a scope that
covers exactly this case, like "compileNotRuntime" or something like that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, Paul Benedict <pb...@apache.org> wrote:
> The Maven folks verified that putting a dependency in
> <scope>provided</scope> will not create a runtime dependency. This
> should equal a compile-only scope.
The problem with that is that the developer has to provide the
annotation jar in order to run the compile. This is an extra stage.
I'm not sure what it involves.
If we can find a method to automate the provision process within the
Maven build, then that would work. Otherwise, we are just making it
awkward for developers.
> PS: Java 7 will not be defining any source-level annotations for bug
> tracking. That will be up to individual tools.
>
>
> On Fri, Mar 20, 2009 at 12:38 AM, Henri Yandell <fl...@gmail.com> wrote:
> > +0 on the idea (tending to +1 with better understanding of the value).
> > I've not used jcip-annotations, but it seems like a good thing to
> > depend upon. Shared concerns with thread:
> >
> > * Adding a dependency is wince-worthy, but I agree with you on it
> > being akin to JUnit and not runtime. We should have confidence in this
> > area and we can beat up on Maven if there are issues in the site.
> >
> > * Java 7 - if these went in would it be painful in any way? Presumably
> > they wouldn't be in java.lang.*. Just raising the 'what would like
> > look like then?' flag.
> >
> > Can you show what source, javadoc, site etc would look like for some
> > example classes?
> >
> > On Wed, Mar 18, 2009 at 8:51 AM, sebb <se...@gmail.com> wrote:
> >> I've added JCIP annotations jar to the POM, but not started adding any
> >> actual annotations yet.
> >>
> >> The idea would be to annotate every class as one of
> >>
> >> @Immutable
> >> @ThreadSafe
> >> @NotThreadSafe
> >>
> >> These annotation appear in the Javadoc output in the class description.
> >>
> >> Also, for objects that need synchronization to ensure thread safety,
> >> add the annotation
> >>
> >> @GuardedBy
> >>
> >> Are there any objections to proceeding with this?
> >>
> >> It's probably easiest to deal with @Immutable first, then @ThreadSafe.
> >>
> >> If no annotation is present, then the user _should_ assume that the
> >> class is @NotThreadSafe, but I think it would be better to always have
> >> an annotation so that it's clear it has not been accidentally left
> >> off.
> >>
> >> WDYT?
> >>
> >> ---------------------------------------------------------------------
> >> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Paul Benedict <pb...@apache.org>.
The Maven folks verified that putting a dependency in
<scope>provided</scope> will not create a runtime dependency. This
should equal a compile-only scope.
PS: Java 7 will not be defining any source-level annotations for bug
tracking. That will be up to individual tools.
On Fri, Mar 20, 2009 at 12:38 AM, Henri Yandell <fl...@gmail.com> wrote:
> +0 on the idea (tending to +1 with better understanding of the value).
> I've not used jcip-annotations, but it seems like a good thing to
> depend upon. Shared concerns with thread:
>
> * Adding a dependency is wince-worthy, but I agree with you on it
> being akin to JUnit and not runtime. We should have confidence in this
> area and we can beat up on Maven if there are issues in the site.
>
> * Java 7 - if these went in would it be painful in any way? Presumably
> they wouldn't be in java.lang.*. Just raising the 'what would like
> look like then?' flag.
>
> Can you show what source, javadoc, site etc would look like for some
> example classes?
>
> On Wed, Mar 18, 2009 at 8:51 AM, sebb <se...@gmail.com> wrote:
>> I've added JCIP annotations jar to the POM, but not started adding any
>> actual annotations yet.
>>
>> The idea would be to annotate every class as one of
>>
>> @Immutable
>> @ThreadSafe
>> @NotThreadSafe
>>
>> These annotation appear in the Javadoc output in the class description.
>>
>> Also, for objects that need synchronization to ensure thread safety,
>> add the annotation
>>
>> @GuardedBy
>>
>> Are there any objections to proceeding with this?
>>
>> It's probably easiest to deal with @Immutable first, then @ThreadSafe.
>>
>> If no annotation is present, then the user _should_ assume that the
>> class is @NotThreadSafe, but I think it would be better to always have
>> an annotation so that it's clear it has not been accidentally left
>> off.
>>
>> WDYT?
>>
>> ---------------------------------------------------------------------
>> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Henri Yandell <fl...@gmail.com>.
+0 on the idea (tending to +1 with better understanding of the value).
I've not used jcip-annotations, but it seems like a good thing to
depend upon. Shared concerns with thread:
* Adding a dependency is wince-worthy, but I agree with you on it
being akin to JUnit and not runtime. We should have confidence in this
area and we can beat up on Maven if there are issues in the site.
* Java 7 - if these went in would it be painful in any way? Presumably
they wouldn't be in java.lang.*. Just raising the 'what would like
look like then?' flag.
Can you show what source, javadoc, site etc would look like for some
example classes?
On Wed, Mar 18, 2009 at 8:51 AM, sebb <se...@gmail.com> wrote:
> I've added JCIP annotations jar to the POM, but not started adding any
> actual annotations yet.
>
> The idea would be to annotate every class as one of
>
> @Immutable
> @ThreadSafe
> @NotThreadSafe
>
> These annotation appear in the Javadoc output in the class description.
>
> Also, for objects that need synchronization to ensure thread safety,
> add the annotation
>
> @GuardedBy
>
> Are there any objections to proceeding with this?
>
> It's probably easiest to deal with @Immutable first, then @ThreadSafe.
>
> If no annotation is present, then the user _should_ assume that the
> class is @NotThreadSafe, but I think it would be better to always have
> an annotation so that it's clear it has not been accidentally left
> off.
>
> WDYT?
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> sebb wrote:
>
> > On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >
> > > 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.
> >
>
> Because [lang] has no dependencies at present. That is a feature.
>
The POM does depend on JUnit for testing.
I have added the dependency as an optional dependency.
> > 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.
> >
>
> But due to the way maven generates documentation, and the data in the pom,
> it will /appear/ like [lang] does have a dependency.
That is a complaint against Maven ;-) but there must be a way to add
some explanation to the site. Given that Maven currently does not
document the JVM requirements, there will need to be some further
information on dependencies on the site anyway.
> Since most users are unaware that annotation dependencies are not needed at
> runtime, they will take the belt and braces approach and include the
> 'dependency'. Or stop using [lang].
As I say, it is flagged as optional.
> > Indeed hopefully users will start adding annotations to their own code...
> >
>
> This change doesn't actually help with that, other than providing
> advertising for JCIP.
>
> I'm basically -0 to this change, as I think the confusion outweighs the
> gains.
>
>
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Thu, Mar 19, 2009 at 11:06 AM, Stephen Colebourne
> <sc...@btopenworld.com> wrote:
> > But due to the way maven generates documentation, and the data in the pom,
> > it will /appear/ like [lang] does have a dependency.
> >
>
>
> We can mark it as optional in our pom. That way, it won't be included
> transitively.
>
It is already.
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Mar 19, 2009 at 11:06 AM, Stephen Colebourne
<sc...@btopenworld.com> wrote:
> But due to the way maven generates documentation, and the data in the pom,
> it will /appear/ like [lang] does have a dependency.
>
We can mark it as optional in our pom. That way, it won't be included
transitively.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 5:01 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> Really though does this stuff work because I tried changing the
> guarded statement you put in ExceptionUtils and findbugs didn't
> complain at all - so seems like the automated checking is broken in at
> least one place.
Does the check have to be turned on?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 20, 2009 at 5:22 PM, sebb <se...@gmail.com> wrote:
> On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
>> On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
>>
>> <sc...@btopenworld.com> wrote:
>> > sebb wrote:
>> >>
>> >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
>> >>>
>> >>> 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.
>> >
>> > Because [lang] has no dependencies at present. That is a feature.
>> >
>> >> 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.
>> >
>> > But due to the way maven generates documentation, and the data in the pom,
>> > it will /appear/ like [lang] does have a dependency.
>> >
>> > Since most users are unaware that annotation dependencies are not needed at
>> > runtime, they will take the belt and braces approach and include the
>> > 'dependency'. Or stop using [lang].
>> >
>> >> Indeed hopefully users will start adding annotations to their own code...
>> >
>> > This change doesn't actually help with that, other than providing
>> > advertising for JCIP.
>> >
>> > I'm basically -0 to this change, as I think the confusion outweighs the
>> > gains.
>>
>>
>> I agree with Stephen.
>>
>> As well as the point he makes its also causing the
>> net.jcip.annotations package to be included in the OSGi Import-Package
>> statement in the manifest which I assume will make this a required
>> dependency when using lang in an OSGi environment. I guess that the
>> maven-bundle-plugin can probably be configured to stop that happening
>> but even if it can then I don't really see the point of using this
>> over just plain comments in the javadocs.
>>
>
> How did you generate the OSGI stuff?
The maven-bundle-plugin is configured in the commons-parent pom so
that all components are built OSGi ready.
I have overriden the default export directive in the Lang pom to
exclude the jcip annotation package and this seems to work (i.e. it no
longer includes the jcip package in the OSGi export statement in
Lang's manifest)
http://svn.apache.org/viewvc?view=rev&revision=756756
Really though does this stuff work because I tried changing the
guarded statement you put in ExceptionUtils and findbugs didn't
complain at all - so seems like the automated checking is broken in at
least one place.
Niall
> I've been experimenting with HC, and I don't see the same behaviour.
>
>> Niall
>>
>>
>>
>> > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, sebb <se...@gmail.com> wrote:
> On 20/03/2009, sebb <se...@gmail.com> wrote:
> > On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
> >
> > > On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
> > >
> > > <sc...@btopenworld.com> wrote:
> > > > sebb wrote:
> > > >>
> > > >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > > >>>
> > > >>> 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.
> > > >
> > > > Because [lang] has no dependencies at present. That is a feature.
> > > >
> > > >> 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.
> > > >
> > > > But due to the way maven generates documentation, and the data in the pom,
> > > > it will /appear/ like [lang] does have a dependency.
> > > >
> > > > Since most users are unaware that annotation dependencies are not needed at
> > > > runtime, they will take the belt and braces approach and include the
> > > > 'dependency'. Or stop using [lang].
> > > >
> > > >> Indeed hopefully users will start adding annotations to their own code...
> > > >
> > > > This change doesn't actually help with that, other than providing
> > > > advertising for JCIP.
> > > >
> > > > I'm basically -0 to this change, as I think the confusion outweighs the
> > > > gains.
> > >
> > >
> > > I agree with Stephen.
> > >
> > > As well as the point he makes its also causing the
> > > net.jcip.annotations package to be included in the OSGi Import-Package
> > > statement in the manifest which I assume will make this a required
> > > dependency when using lang in an OSGi environment. I guess that the
> > > maven-bundle-plugin can probably be configured to stop that happening
> > > but even if it can then I don't really see the point of using this
> > > over just plain comments in the javadocs.
> > >
> >
> >
> > How did you generate the OSGI stuff?
> >
> > I've been experimenting with HC, and I don't see the same behaviour.
> >
>
>
> Take 2:
>
> Just found a problem when using compile+optional in HC:
>
> The generated bundle:
> org.apache.httpcomponents.httpcore_4.1-SNAPSHOT.jar
> contains a valid DEPENDENCIES file.
> The MANIFEST looks OK too, no mention of jcip
>
> However, the included archive:
> httpcore-nio-4.1-SNAPSHOT.jar
> has a DEPENDENCIES file which refers to JCIP.
>
> Not sure if this is a problem for OSGI or not, but it is not consistent.
>
It gets messier - when I then build HC Client, the OSGI jar
org.apache.httpcomponents.httpclient_4.0-beta3-SNAPSHOT.jar
has a DEPENDENCIES file that is OK, but the MANIFEST now includes JCIP.
The embedded jars
httpclient-4.0-beta3-SNAPSHOT.jar
httpmime-4.0-beta3-SNAPSHOT.jar
have DEPENDENCIES files that include JCIP
Looks like there is a problem with handling optional dependencies
across projects.
> > > Niall
> > >
> > >
> > >
> > > > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 2:14 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Fri, Mar 20, 2009 at 2:11 PM, sebb <se...@gmail.com> wrote:
>>> How about we fix the felix plugin?
>>
>> We?
>
> We as in the ASF. If we've got a beef with it, we should report it to
> them. Perhaps it has already been reported?
FYI:
http://issues.apache.org/jira/browse/FELIX-954
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 2:11 PM, sebb <se...@gmail.com> wrote:
>> How about we fix the felix plugin?
>
> We?
We as in the ASF. If we've got a beef with it, we should report it to
them. Perhaps it has already been reported?
>
>> Or can't we tell it to ignore that stuff somehow via configuration?
>
> So long as the configuration override works for other projects that
> declare dependencies on such projects - and so on - that seems like a
> possible work-round.
>
> However - given that the problem appears to be due to incorrect
> handling of non-transitive dependencies - that may not work.
Perhaps we should include the felix folks in on our discussion? They
may be able to help us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Fri, Mar 20, 2009 at 1:50 PM, sebb <se...@gmail.com> wrote:
> >
> > Take 2:
> >
> > Just found a problem when using compile+optional in HC:
> >
> > The generated bundle:
> > org.apache.httpcomponents.httpcore_4.1-SNAPSHOT.jar
> > contains a valid DEPENDENCIES file.
> > The MANIFEST looks OK too, no mention of jcip
> >
> > However, the included archive:
> > httpcore-nio-4.1-SNAPSHOT.jar
> > has a DEPENDENCIES file which refers to JCIP.
> >
> > Not sure if this is a problem for OSGI or not, but it is not consistent.
>
>
> Ok, I understand that we want to make sure OSGi bundles work
> correctly. But, misusing maven's dependency declaration because one
> specific plugin doesn't work properly with the correct way to do it
> doesn't seem right to me.
Agreed - I think!
> How about we fix the felix plugin?
We?
> Or can't we tell it to ignore that stuff somehow via configuration?
So long as the configuration override works for other projects that
declare dependencies on such projects - and so on - that seems like a
possible work-round.
However - given that the problem appears to be due to incorrect
handling of non-transitive dependencies - that may not work.
>
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Fri, Mar 20, 2009 at 1:50 PM, sebb <se...@gmail.com> wrote:
>
> Take 2:
>
> Just found a problem when using compile+optional in HC:
>
> The generated bundle:
> org.apache.httpcomponents.httpcore_4.1-SNAPSHOT.jar
> contains a valid DEPENDENCIES file.
> The MANIFEST looks OK too, no mention of jcip
>
> However, the included archive:
> httpcore-nio-4.1-SNAPSHOT.jar
> has a DEPENDENCIES file which refers to JCIP.
>
> Not sure if this is a problem for OSGI or not, but it is not consistent.
Ok, I understand that we want to make sure OSGi bundles work
correctly. But, misusing maven's dependency declaration because one
specific plugin doesn't work properly with the correct way to do it
doesn't seem right to me. How about we fix the felix plugin? Or,
can't we tell it to ignore that stuff somehow via configuration?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, sebb <se...@gmail.com> wrote:
> On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
>
> > On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
> >
> > <sc...@btopenworld.com> wrote:
> > > sebb wrote:
> > >>
> > >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > >>>
> > >>> 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.
> > >
> > > Because [lang] has no dependencies at present. That is a feature.
> > >
> > >> 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.
> > >
> > > But due to the way maven generates documentation, and the data in the pom,
> > > it will /appear/ like [lang] does have a dependency.
> > >
> > > Since most users are unaware that annotation dependencies are not needed at
> > > runtime, they will take the belt and braces approach and include the
> > > 'dependency'. Or stop using [lang].
> > >
> > >> Indeed hopefully users will start adding annotations to their own code...
> > >
> > > This change doesn't actually help with that, other than providing
> > > advertising for JCIP.
> > >
> > > I'm basically -0 to this change, as I think the confusion outweighs the
> > > gains.
> >
> >
> > I agree with Stephen.
> >
> > As well as the point he makes its also causing the
> > net.jcip.annotations package to be included in the OSGi Import-Package
> > statement in the manifest which I assume will make this a required
> > dependency when using lang in an OSGi environment. I guess that the
> > maven-bundle-plugin can probably be configured to stop that happening
> > but even if it can then I don't really see the point of using this
> > over just plain comments in the javadocs.
> >
>
>
> How did you generate the OSGI stuff?
>
> I've been experimenting with HC, and I don't see the same behaviour.
>
Take 2:
Just found a problem when using compile+optional in HC:
The generated bundle:
org.apache.httpcomponents.httpcore_4.1-SNAPSHOT.jar
contains a valid DEPENDENCIES file.
The MANIFEST looks OK too, no mention of jcip
However, the included archive:
httpcore-nio-4.1-SNAPSHOT.jar
has a DEPENDENCIES file which refers to JCIP.
Not sure if this is a problem for OSGI or not, but it is not consistent.
> > Niall
> >
> >
> >
> > > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
> On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
>
> <sc...@btopenworld.com> wrote:
> > sebb wrote:
> >>
> >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>>
> >>> 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.
> >
> > Because [lang] has no dependencies at present. That is a feature.
> >
> >> 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.
> >
> > But due to the way maven generates documentation, and the data in the pom,
> > it will /appear/ like [lang] does have a dependency.
> >
> > Since most users are unaware that annotation dependencies are not needed at
> > runtime, they will take the belt and braces approach and include the
> > 'dependency'. Or stop using [lang].
> >
> >> Indeed hopefully users will start adding annotations to their own code...
> >
> > This change doesn't actually help with that, other than providing
> > advertising for JCIP.
> >
> > I'm basically -0 to this change, as I think the confusion outweighs the
> > gains.
>
>
> I agree with Stephen.
>
> As well as the point he makes its also causing the
> net.jcip.annotations package to be included in the OSGi Import-Package
> statement in the manifest which I assume will make this a required
> dependency when using lang in an OSGi environment. I guess that the
> maven-bundle-plugin can probably be configured to stop that happening
> but even if it can then I don't really see the point of using this
> over just plain comments in the javadocs.
>
How did you generate the OSGI stuff?
I've been experimenting with HC, and I don't see the same behaviour.
> Niall
>
>
>
> > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Paul Benedict <pb...@apache.org>.
Sebb,
After Lang 3.0 gets released, why not branch just for the JCIP stuff?
Sometimes you can only convince my demonstration. I think that would
be an acceptable evaluation.
Paul
On Thu, Mar 19, 2009 at 9:26 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Fri, Mar 20, 2009 at 1:24 AM, sebb <se...@gmail.com> wrote:
>> On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
>>>
>>> <sc...@btopenworld.com> wrote:
>>> > sebb wrote:
>>> >>
>>> >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
>>> >>>
>>> >>> 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.
>>> >
>>> > Because [lang] has no dependencies at present. That is a feature.
>>> >
>>> >> 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.
>>> >
>>> > But due to the way maven generates documentation, and the data in the pom,
>>> > it will /appear/ like [lang] does have a dependency.
>>> >
>>> > Since most users are unaware that annotation dependencies are not needed at
>>> > runtime, they will take the belt and braces approach and include the
>>> > 'dependency'. Or stop using [lang].
>>> >
>>> >> Indeed hopefully users will start adding annotations to their own code...
>>> >
>>> > This change doesn't actually help with that, other than providing
>>> > advertising for JCIP.
>>> >
>>> > I'm basically -0 to this change, as I think the confusion outweighs the
>>> > gains.
>>>
>>>
>>> I agree with Stephen.
>>>
>>> As well as the point he makes its also causing the
>>> net.jcip.annotations package to be included in the OSGi Import-Package
>>> statement in the manifest which I assume will make this a required
>>> dependency when using lang in an OSGi environment. I guess that the
>>> maven-bundle-plugin can probably be configured to stop that happening
>>> but even if it can then I don't really see the point of using this
>>> over just plain comments in the javadocs.
>>
>> The point is that the annotations can be checked using automated
>> tools, so changes that break the contract are detected. Much the same
>> reason as using generics.
>
> Theres a question over whether this is actually working ATM.
>
>> means to automate checking it. Updating Javadoc is as much work but no
>> a automated checking benefit.
>>
>> Seems to me that most of the reasons for not implementing this are
>> that Maven does not seem handle the compile-time only dependency
>> properly.
>
> True but thats our build tool of choice ATM and this feature is only
> for documenting/checking and doesn't actually add anything to Lang's
> functionality - esp when it could just be as easily documented in the
> javadocs without the annotations.
>
> Niall
>
>>>
>>> Niall
>>>
>>>
>>>
>>> > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 20, 2009 at 1:24 AM, sebb <se...@gmail.com> wrote:
> On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
>> On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
>>
>> <sc...@btopenworld.com> wrote:
>> > sebb wrote:
>> >>
>> >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
>> >>>
>> >>> 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.
>> >
>> > Because [lang] has no dependencies at present. That is a feature.
>> >
>> >> 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.
>> >
>> > But due to the way maven generates documentation, and the data in the pom,
>> > it will /appear/ like [lang] does have a dependency.
>> >
>> > Since most users are unaware that annotation dependencies are not needed at
>> > runtime, they will take the belt and braces approach and include the
>> > 'dependency'. Or stop using [lang].
>> >
>> >> Indeed hopefully users will start adding annotations to their own code...
>> >
>> > This change doesn't actually help with that, other than providing
>> > advertising for JCIP.
>> >
>> > I'm basically -0 to this change, as I think the confusion outweighs the
>> > gains.
>>
>>
>> I agree with Stephen.
>>
>> As well as the point he makes its also causing the
>> net.jcip.annotations package to be included in the OSGi Import-Package
>> statement in the manifest which I assume will make this a required
>> dependency when using lang in an OSGi environment. I guess that the
>> maven-bundle-plugin can probably be configured to stop that happening
>> but even if it can then I don't really see the point of using this
>> over just plain comments in the javadocs.
>
> The point is that the annotations can be checked using automated
> tools, so changes that break the contract are detected. Much the same
> reason as using generics.
Theres a question over whether this is actually working ATM.
> means to automate checking it. Updating Javadoc is as much work but no
> a automated checking benefit.
>
> Seems to me that most of the reasons for not implementing this are
> that Maven does not seem handle the compile-time only dependency
> properly.
True but thats our build tool of choice ATM and this feature is only
for documenting/checking and doesn't actually add anything to Lang's
functionality - esp when it could just be as easily documented in the
javadocs without the annotations.
Niall
>>
>> Niall
>>
>>
>>
>> > Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 20/03/2009, Niall Pemberton <ni...@gmail.com> wrote:
> On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
>
> <sc...@btopenworld.com> wrote:
> > sebb wrote:
> >>
> >> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> >>>
> >>> 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.
> >
> > Because [lang] has no dependencies at present. That is a feature.
> >
> >> 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.
> >
> > But due to the way maven generates documentation, and the data in the pom,
> > it will /appear/ like [lang] does have a dependency.
> >
> > Since most users are unaware that annotation dependencies are not needed at
> > runtime, they will take the belt and braces approach and include the
> > 'dependency'. Or stop using [lang].
> >
> >> Indeed hopefully users will start adding annotations to their own code...
> >
> > This change doesn't actually help with that, other than providing
> > advertising for JCIP.
> >
> > I'm basically -0 to this change, as I think the confusion outweighs the
> > gains.
>
>
> I agree with Stephen.
>
> As well as the point he makes its also causing the
> net.jcip.annotations package to be included in the OSGi Import-Package
> statement in the manifest which I assume will make this a required
> dependency when using lang in an OSGi environment. I guess that the
> maven-bundle-plugin can probably be configured to stop that happening
> but even if it can then I don't really see the point of using this
> over just plain comments in the javadocs.
The point is that the annotations can be checked using automated
tools, so changes that break the contract are detected. Much the same
reason as using generics.
Adding an annotation serves both to document the code and provides a
means to automate checking it. Updating Javadoc is as much work but no
a automated checking benefit.
Seems to me that most of the reasons for not implementing this are
that Maven does not seem handle the compile-time only dependency
properly.
>
> Niall
>
>
>
> > 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Mar 19, 2009 at 3:06 PM, Stephen Colebourne
<sc...@btopenworld.com> wrote:
> sebb wrote:
>>
>> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
>>>
>>> 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.
>
> Because [lang] has no dependencies at present. That is a feature.
>
>> 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.
>
> But due to the way maven generates documentation, and the data in the pom,
> it will /appear/ like [lang] does have a dependency.
>
> Since most users are unaware that annotation dependencies are not needed at
> runtime, they will take the belt and braces approach and include the
> 'dependency'. Or stop using [lang].
>
>> Indeed hopefully users will start adding annotations to their own code...
>
> This change doesn't actually help with that, other than providing
> advertising for JCIP.
>
> I'm basically -0 to this change, as I think the confusion outweighs the
> gains.
I agree with Stephen.
As well as the point he makes its also causing the
net.jcip.annotations package to be included in the OSGi Import-Package
statement in the manifest which I assume will make this a required
dependency when using lang in an OSGi environment. I guess that the
maven-bundle-plugin can probably be configured to stop that happening
but even if it can then I don't really see the point of using this
over just plain comments in the javadocs.
Niall
> Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by Stephen Colebourne <sc...@btopenworld.com>.
sebb wrote:
> On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
>> 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.
Because [lang] has no dependencies at present. That is a feature.
> 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.
But due to the way maven generates documentation, and the data in the
pom, it will /appear/ like [lang] does have a dependency.
Since most users are unaware that annotation dependencies are not needed
at runtime, they will take the belt and braces approach and include the
'dependency'. Or stop using [lang].
> Indeed hopefully users will start adding annotations to their own code...
This change doesn't actually help with that, other than providing
advertising for JCIP.
I'm basically -0 to this change, as I think the confusion outweighs the
gains.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [LANG] 3.0 JCIP Annotations
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com] On
> Behalf Of Paul Benedict
> Sent: Thursday, March 19, 2009 5:37 AM
> To: Commons Developers List
> Subject: Re: [LANG] 3.0 JCIP Annotations
>
> 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.
I love avoiding duplication. It's too bad we can't do the same for code, even just within [commons] as well as Apache-wide.
We use a lot of [commons], Apache libraries and other open source projects. Over and over I see code duplicated under the rubric 'we don't want to depend on foo.jar, so copy the foo code here'.
If you use an IDE like Eclipse, just search for classes like Base64 and StringUtils, there are a lot of them out there! Granted they do not all do the exactly same thing. It would be interesting to have a way for a build or Gump to look for code duplication across projects, even duplicated class names could be a hint that one project could reuse another...
Gary
>
> Paul
>
> On Thu, Mar 19, 2009 at 6:07 AM, sebb <se...@gmail.com> wrote:
> > On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
> >> > On 19/03/2009, Stephen Colebourne <sc...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
> > On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
> >> > On 19/03/2009, Stephen Colebourne <sc...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, *if* a project wants to use it, they should all use the same
thing. That way, we can put something in the parent pom file that
uses the annotations.
On Thu, Mar 19, 2009 at 8:36 AM, Paul Benedict <pb...@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.
>
> Paul
>
> On Thu, Mar 19, 2009 at 6:07 AM, sebb <se...@gmail.com> wrote:
>> On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
>>> > On 19/03/2009, Stephen Colebourne <sc...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by Paul Benedict <pb...@apache.org>.
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 <se...@gmail.com> wrote:
> On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
>> > On 19/03/2009, Stephen Colebourne <sc...@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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, Paul Benedict <pb...@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 <se...@gmail.com> wrote:
> > On 19/03/2009, Stephen Colebourne <sc...@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
Re: [LANG] 3.0 JCIP Annotations
Posted by Paul Benedict <pb...@apache.org>.
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.
Paul
On Wed, Mar 18, 2009 at 9:48 PM, sebb <se...@gmail.com> wrote:
> On 19/03/2009, Stephen Colebourne <sc...@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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, Stephen Colebourne <sc...@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
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, James Carman <ja...@carmanconsulting.com> wrote:
> On Wed, Mar 18, 2009 at 10:21 PM, Stephen Colebourne
> <sc...@btopenworld.com> wrote:
> >
> > 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.
> >
>
>
> I agree. Most folks don't know that there annotation classes aren't
> really required at runtime. If we're just looking for documentation,
> can't we have our own doclet?
>
The fact that the annotations are included in the Javadoc is a bonus,
not a requirement.
The thread-safety information needs to be present, anyway.
Using annotations means that automated tools such as Findbugs can
generate a warning if the requirements are not met, as well as
documenting the behaviour for future maintenance.
> ---------------------------------------------------------------------
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Mar 18, 2009 at 10:21 PM, Stephen Colebourne
<sc...@btopenworld.com> wrote:
>
> 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.
>
I agree. Most folks don't know that there annotation classes aren't
really required at runtime. If we're just looking for documentation,
can't we have our own doclet?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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...)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 19/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> sebb wrote:
>
> >
> > > I think that there is the distinct possibility of other groups
> including
> > > these annotatons. Maybe even JDK7. Should [lang] include them. Or use
> > > slightly different names?
> > >
> >
> > Not sure I follow.
> >
> > These are existing annotations, from http://jcip.net/:
> >
> > http://jcip.net/annotations/doc/index.html
> >
> > [Sorry, I forgot to reference my original posting to the LANG thread:
> >
> >
> http://www.nabble.com/Re%3A--lang--3.0%2C-what%27s-in--what%27s-out-p22511906.html
> >
> > ]
> >
>
> 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.
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Stephen Colebourne <sc...@btopenworld.com>.
sebb wrote:
>> I think that there is the distinct possibility of other groups including
>> these annotatons. Maybe even JDK7. Should [lang] include them. Or use
>> slightly different names?
>
> Not sure I follow.
>
> These are existing annotations, from http://jcip.net/:
>
> http://jcip.net/annotations/doc/index.html
>
> [Sorry, I forgot to reference my original posting to the LANG thread:
>
> http://www.nabble.com/Re%3A--lang--3.0%2C-what%27s-in--what%27s-out-p22511906.html
>
> ]
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)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
Posted by sebb <se...@gmail.com>.
On 18/03/2009, Stephen Colebourne <sc...@btopenworld.com> wrote:
> sebb wrote:
>
> > I've added JCIP annotations jar to the POM, but not started adding any
> > actual annotations yet.
> >
> > The idea would be to annotate every class as one of
> >
> > @Immutable
> > @ThreadSafe
> > @NotThreadSafe
> >
> > These annotation appear in the Javadoc output in the class description.
> >
> > Also, for objects that need synchronization to ensure thread safety,
> > add the annotation
> >
> > @GuardedBy
> >
> > Are there any objections to proceeding with this?
> >
>
> I think that there is the distinct possibility of other groups including
> these annotatons. Maybe even JDK7. Should [lang] include them. Or use
> slightly different names?
Not sure I follow.
These are existing annotations, from http://jcip.net/:
http://jcip.net/annotations/doc/index.html
[Sorry, I forgot to reference my original posting to the LANG thread:
http://www.nabble.com/Re%3A--lang--3.0%2C-what%27s-in--what%27s-out-p22511906.html
]
The Findbugs project ships with a copy, but the original copy is
Creative Commons rather than LGPL.
> 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
Re: [LANG] 3.0 JCIP Annotations
Posted by Stephen Colebourne <sc...@btopenworld.com>.
sebb wrote:
> I've added JCIP annotations jar to the POM, but not started adding any
> actual annotations yet.
>
> The idea would be to annotate every class as one of
>
> @Immutable
> @ThreadSafe
> @NotThreadSafe
>
> These annotation appear in the Javadoc output in the class description.
>
> Also, for objects that need synchronization to ensure thread safety,
> add the annotation
>
> @GuardedBy
>
> Are there any objections to proceeding with this?
I think that there is the distinct possibility of other groups including
these annotatons. Maybe even JDK7. Should [lang] include them. Or use
slightly different names?
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org