Re: [lang] new concurrency annotations

[Gary Gregory]

On Thu, Apr 20, 2017 at 2:53 PM, Gary Gregory 
wrote:

>
> On Wed, Apr 19, 2017 at 1:00 PM, Gary Gregory 
> wrote:
>
>> Related to this, is HttpCore which switch from JCIP style annotations
>> (4.x) to @Contract (5.x). I'll ask that ML for the reason/experience.
>>
>
> Acoording to Oleg:
> --
> The original JCIP style annotations had to be removed due to ASLv2
> incompatibility with the license of the original work.
>
> There is a corresponding Jira ticket in LEGAL.
> --
>

Found these two:

https://issues.apache.org/jira/browse/LEGAL-240
https://issues.apache.org/jira/browse/LEGAL-3

Gary


> Gary
>
>
>>
>> Gary
>>
>> On Wed, Apr 19, 2017 at 12:14 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>>
>>>
>>>
>>> Am 19.04.2017 um 14:06 schrieb Gilles:
>>> > On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:
>>> >> Le 19/04/2017 à 00:23, Gary Gregory a écrit :
>>> >>
>>> >>> I'd like to see a real example before we talk about abstract
>>> >>> arguments and
>>> >>> counter-arguments, which will never end ;-)
>>> >>
>>> >> Ok,
>>> >
>>> > Good. [If only...] ;-)
>>> >
>>> >> here is a slightly more substantial example. The following class is
>>> >> immutable but not thread-safe:
>>> >>
>>> >>   public class FileAppender {
>>> >>   private final File file;
>>> >>
>>> >>   public FileAppender(File file) {
>>> >>   this.file = file;
>>> >>   }
>>> >>
>>> >>   public void append(String message) throws IOException {
>>> >>   try (OutputStream out = new FileOutputStream(file)) {
>>> >>   out.write(message.getBytes());
>>> >>   }
>>> >>   }
>>> >>   }
>>> >>
>>> >> The point is, if the class operates on resources outside the JVM, the
>>> >> immutability doesn't ensure the thread safety. Immutability is only a
>>> >> thread safety guarantee for data structures, and not for classes with
>>> >> operations causing side effects (like writing to files, drawing on the
>>> >> screen, playing sounds, calling remote services, accessing off-heap
>>> >> memory, etc).
>>> >
>>> > The consequence should thus be that such classes should not be
>>> > documented as thread-safe _because_ such a qualifier would not
>>> > bring any actual benefit to the user.
>>> >
>>> > Documenting/annotating a class as "immutable" or "thread-safe"
>>> > must be a _promise_ to the user, and it requires more analysis
>>> > than recognizing that all the fields are final.
>>> >
>>> > To return to the question of which annotation, I'm unfazed by
>>> > the possibility of
>>> >  @ThreadSafe
>>> >  @NotThreadSafe
>>> > because it is an obvious documentation bug, with no more dire
>>> > consequences than saying
>>> >  @ThreadSafe
>>> > when, in fact, it is not.
>>> >
>>> I agree. Let's not forget that the annotations are intended as a tool
>>> for documentation. The main responsibility is on the author who is using
>>> them.
>>>
>>> We should not try to be too clever here, especially as we have no way to
>>> prevent real documentation errors: classes being marked as @ThreadSafe
>>> although they are not, or originally thread-safe classes which are later
>>> modified in a way that breaks their thread-safety.
>>>
>>> Oliver
>>>
>>> >
>>> > Gilles
>>> >
>>> >>
>>> >> Emmanuel Bourg
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > For additional commands, e-mail: dev-h...@commons.apache.org
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>>
>> 
>> JUnit in Action, Second Edition
>> 
>>
>> 
>> Spring Batch in Action
>> 
>> 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
>

Re: [lang] new concurrency annotations

[Gary Gregory]

Related to this, is HttpCore which switch from JCIP style annotations (4.x)
to @Contract (5.x). I'll ask that ML for the reason/experience.

Gary

On Wed, Apr 19, 2017 at 12:14 PM, Oliver Heger  wrote:

>
>
> Am 19.04.2017 um 14:06 schrieb Gilles:
> > On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:
> >> Le 19/04/2017 à 00:23, Gary Gregory a écrit :
> >>
> >>> I'd like to see a real example before we talk about abstract
> >>> arguments and
> >>> counter-arguments, which will never end ;-)
> >>
> >> Ok,
> >
> > Good. [If only...] ;-)
> >
> >> here is a slightly more substantial example. The following class is
> >> immutable but not thread-safe:
> >>
> >>   public class FileAppender {
> >>   private final File file;
> >>
> >>   public FileAppender(File file) {
> >>   this.file = file;
> >>   }
> >>
> >>   public void append(String message) throws IOException {
> >>   try (OutputStream out = new FileOutputStream(file)) {
> >>   out.write(message.getBytes());
> >>   }
> >>   }
> >>   }
> >>
> >> The point is, if the class operates on resources outside the JVM, the
> >> immutability doesn't ensure the thread safety. Immutability is only a
> >> thread safety guarantee for data structures, and not for classes with
> >> operations causing side effects (like writing to files, drawing on the
> >> screen, playing sounds, calling remote services, accessing off-heap
> >> memory, etc).
> >
> > The consequence should thus be that such classes should not be
> > documented as thread-safe _because_ such a qualifier would not
> > bring any actual benefit to the user.
> >
> > Documenting/annotating a class as "immutable" or "thread-safe"
> > must be a _promise_ to the user, and it requires more analysis
> > than recognizing that all the fields are final.
> >
> > To return to the question of which annotation, I'm unfazed by
> > the possibility of
> >  @ThreadSafe
> >  @NotThreadSafe
> > because it is an obvious documentation bug, with no more dire
> > consequences than saying
> >  @ThreadSafe
> > when, in fact, it is not.
> >
> I agree. Let's not forget that the annotations are intended as a tool
> for documentation. The main responsibility is on the author who is using
> them.
>
> We should not try to be too clever here, especially as we have no way to
> prevent real documentation errors: classes being marked as @ThreadSafe
> although they are not, or originally thread-safe classes which are later
> modified in a way that breaks their thread-safety.
>
> Oliver
>
> >
> > Gilles
> >
> >>
> >> Emmanuel Bourg
> >>
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Oliver Heger]

Am 19.04.2017 um 14:06 schrieb Gilles:
> On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:
>> Le 19/04/2017 à 00:23, Gary Gregory a écrit :
>>
>>> I'd like to see a real example before we talk about abstract
>>> arguments and
>>> counter-arguments, which will never end ;-)
>>
>> Ok,
> 
> Good. [If only...] ;-)
> 
>> here is a slightly more substantial example. The following class is
>> immutable but not thread-safe:
>>
>>   public class FileAppender {
>>   private final File file;
>>
>>   public FileAppender(File file) {
>>   this.file = file;
>>   }
>>
>>   public void append(String message) throws IOException {
>>   try (OutputStream out = new FileOutputStream(file)) {
>>   out.write(message.getBytes());
>>   }
>>   }
>>   }
>>
>> The point is, if the class operates on resources outside the JVM, the
>> immutability doesn't ensure the thread safety. Immutability is only a
>> thread safety guarantee for data structures, and not for classes with
>> operations causing side effects (like writing to files, drawing on the
>> screen, playing sounds, calling remote services, accessing off-heap
>> memory, etc).
> 
> The consequence should thus be that such classes should not be
> documented as thread-safe _because_ such a qualifier would not
> bring any actual benefit to the user.
> 
> Documenting/annotating a class as "immutable" or "thread-safe"
> must be a _promise_ to the user, and it requires more analysis
> than recognizing that all the fields are final.
> 
> To return to the question of which annotation, I'm unfazed by
> the possibility of
>  @ThreadSafe
>  @NotThreadSafe
> because it is an obvious documentation bug, with no more dire
> consequences than saying
>  @ThreadSafe
> when, in fact, it is not.
> 
I agree. Let's not forget that the annotations are intended as a tool
for documentation. The main responsibility is on the author who is using
them.

We should not try to be too clever here, especially as we have no way to
prevent real documentation errors: classes being marked as @ThreadSafe
although they are not, or originally thread-safe classes which are later
modified in a way that breaks their thread-safety.

Oliver

> 
> Gilles
> 
>>
>> Emmanuel Bourg
>>
>>
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

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

Re: [lang] new concurrency annotations

[Gilles]

On Wed, 19 Apr 2017 09:17:32 +0200, Emmanuel Bourg wrote:

Le 19/04/2017 à 00:23, Gary Gregory a écrit :

I'd like to see a real example before we talk about abstract 
arguments and

counter-arguments, which will never end ;-)


Ok,


Good. [If only...] ;-)


here is a slightly more substantial example. The following class is
immutable but not thread-safe:

  public class FileAppender {
  private final File file;

  public FileAppender(File file) {
  this.file = file;
  }

  public void append(String message) throws IOException {
  try (OutputStream out = new FileOutputStream(file)) {
  out.write(message.getBytes());
  }
  }
  }

The point is, if the class operates on resources outside the JVM, the
immutability doesn't ensure the thread safety. Immutability is only a
thread safety guarantee for data structures, and not for classes with
operations causing side effects (like writing to files, drawing on 
the

screen, playing sounds, calling remote services, accessing off-heap
memory, etc).


The consequence should thus be that such classes should not be
documented as thread-safe _because_ such a qualifier would not
bring any actual benefit to the user.

Documenting/annotating a class as "immutable" or "thread-safe"
must be a _promise_ to the user, and it requires more analysis
than recognizing that all the fields are final.

To return to the question of which annotation, I'm unfazed by
the possibility of
 @ThreadSafe
 @NotThreadSafe
because it is an obvious documentation bug, with no more dire
consequences than saying
 @ThreadSafe
when, in fact, it is not.


Gilles



Emmanuel Bourg






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

Re: [lang] new concurrency annotations

[Emmanuel Bourg]

Le 19/04/2017 à 00:23, Gary Gregory a écrit :

> I'd like to see a real example before we talk about abstract arguments and
> counter-arguments, which will never end ;-)

Ok, here is a slightly more substantial example. The following class is
immutable but not thread-safe:

  public class FileAppender {
  private final File file;

  public FileAppender(File file) {
  this.file = file;
  }

  public void append(String message) throws IOException {
  try (OutputStream out = new FileOutputStream(file)) {
  out.write(message.getBytes());
  }
  }
  }

The point is, if the class operates on resources outside the JVM, the
immutability doesn't ensure the thread safety. Immutability is only a
thread safety guarantee for data structures, and not for classes with
operations causing side effects (like writing to files, drawing on the
screen, playing sounds, calling remote services, accessing off-heap
memory, etc).

Emmanuel Bourg


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

Re: [lang] new concurrency annotations

[Benedikt Ritter]

Hi,

> Am 19.04.2017 um 00:14 schrieb Gary Gregory :
> 
> I'm OK with dropping them for 3.6 to avoid blocking the release and talking
> some more. Either way.

Okay, I’ll remove them from the code base before I prepare RC2.

Benedikt

> 
> Gary
> 
> On Tue, Apr 18, 2017 at 2:30 PM, Pascal Schumacher > wrote:
> 
>> I'm fine with either variant. We should not forget that the reason for
>> adding these annotations was documenting thread-safety of lang classes.
>> This should not hold up the release, the feature can be postponed to 3.7 if
>> it requires further discussion/thought.
>> 
>> Cheers,
>> Pascal
>> 
>> 
>> Am 18.04.2017 um 08:36 schrieb Gary Gregory:
>> 
>>> Hi All:
>>> 
>>> We have two styles for the new concurrency annotations in master:
>>> 
>>> (1) JCIP
>>> (2) Apache HttpComponents Core
>>> 
>>> I would like to delete (1) in favor of (2). I started this discussion
>>> inappropriately on a VOTE thread, sorry for the redo.
>>> 
>>> Then we can proceed with another release candidate.
>>> 
>>> Also at issue is where the new annotations belong
>>> 
>>> (1) org.apache.commons.lang3.concurrent.annotation (current)
>>> (2) org.apache.commons.lang3.annotation (my preferred location)
>>> 
>>> Thoughts?
>>> 
>>> Gary
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> 
> 
> JUnit in Action, Second Edition
> 
> 
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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

Re: [lang] new concurrency annotations

[Gary Gregory]

On Tue, Apr 18, 2017 at 2:14 PM, Emmanuel Bourg  wrote:

> Le 18/04/2017 à 23:06, Gary Gregory a écrit :
>
> > This use case does not make sense to me. If an object is immutable, then
> it
> > is thread safe. If you want to include an asynchronous external resource
> as
> > part of your object, then the object might not be in fact, immutable.
> > Speaking of a specific use case would be better.
>
> What about something like a FileOutputStream?


A JRE FileOutputStream (Oracle Java 8) is not immutable.


> The object fields could be
> final (the file descriptor never changes), but the write methods can't
> be safely called concurrently.
>
> Another example would be an interface to a remote service. The stub
> could be immutable and contain the URL of the remote service, but the
> operations couldn't be called by multiple threads.
>

I'd like to see a real example before we talk about abstract arguments and
counter-arguments, which will never end ;-)

I mean, OK you have a service, with a final URL and no other state. So the
"invoke" method creates all the resources it needs, so that's thread-safe.
If you want a not thread-safe design, then you save these resources in
instance variables for reuse. You'd allocate those in the ctor to make them
final in order to keep the object immutable. Then we get into the usual
discussion that no class is final unless all of its ivars are final. And if
each ivar is also an Object, IT must be immutable to call the composite
immutable.

All of this to say, that having final non-primitive instance variables does
not make a class immutable (transitively). So maybe we need to allow for
that level of documentation IMMUTABLE vs. IMMUTABLE_TRANSITIVE.

Gary


>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Gary Gregory]

I'm OK with dropping them for 3.6 to avoid blocking the release and talking
some more. Either way.

Gary

On Tue, Apr 18, 2017 at 2:30 PM, Pascal Schumacher  wrote:

> I'm fine with either variant. We should not forget that the reason for
> adding these annotations was documenting thread-safety of lang classes.
> This should not hold up the release, the feature can be postponed to 3.7 if
> it requires further discussion/thought.
>
> Cheers,
> Pascal
>
>
> Am 18.04.2017 um 08:36 schrieb Gary Gregory:
>
>> Hi All:
>>
>> We have two styles for the new concurrency annotations in master:
>>
>> (1) JCIP
>> (2) Apache HttpComponents Core
>>
>> I would like to delete (1) in favor of (2). I started this discussion
>> inappropriately on a VOTE thread, sorry for the redo.
>>
>> Then we can proceed with another release candidate.
>>
>> Also at issue is where the new annotations belong
>>
>> (1) org.apache.commons.lang3.concurrent.annotation (current)
>> (2) org.apache.commons.lang3.annotation (my preferred location)
>>
>> Thoughts?
>>
>> Gary
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Pascal Schumacher]

I'm fine with either variant. We should not forget that the reason for 
adding these annotations was documenting thread-safety of lang classes. 
This should not hold up the release, the feature can be postponed to 3.7 
if it requires further discussion/thought.


Cheers,
Pascal


Am 18.04.2017 um 08:36 schrieb Gary Gregory:

Hi All:

We have two styles for the new concurrency annotations in master:

(1) JCIP
(2) Apache HttpComponents Core

I would like to delete (1) in favor of (2). I started this discussion
inappropriately on a VOTE thread, sorry for the redo.

Then we can proceed with another release candidate.

Also at issue is where the new annotations belong

(1) org.apache.commons.lang3.concurrent.annotation (current)
(2) org.apache.commons.lang3.annotation (my preferred location)

Thoughts?

Gary




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

Re: [lang] new concurrency annotations

[Emmanuel Bourg]

Le 18/04/2017 à 23:06, Gary Gregory a écrit :

> This use case does not make sense to me. If an object is immutable, then it
> is thread safe. If you want to include an asynchronous external resource as
> part of your object, then the object might not be in fact, immutable.
> Speaking of a specific use case would be better.

What about something like a FileOutputStream? The object fields could be
final (the file descriptor never changes), but the write methods can't
be safely called concurrently.

Another example would be an interface to a remote service. The stub
could be immutable and contain the URL of the remote service, but the
operations couldn't be called by multiple threads.

Emmanuel Bourg


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

Re: [lang] new concurrency annotations

[Gary Gregory]

On Tue, Apr 18, 2017 at 8:38 AM, Emmanuel Bourg  wrote:

> Le 18/04/2017 à 08:36, Gary Gregory a écrit :
>
> > Thoughts?
>
> I think I tend to prefer the JCIP style. ThreadingBehavior conflates the
> notions of thread safety and immutability and intuitively I'd keep them
> separate, even if they are often closely related.


IMO this is OK because immutability implies thread safety, while thread
safety does not imply immutability.


> An object could be
> immutable and not thread safe because it operates on an external
> resource that doesn't work concurrently.
>

This use case does not make sense to me. If an object is immutable, then it
is thread safe. If you want to include an asynchronous external resource as
part of your object, then the object might not be in fact, immutable.
Speaking of a specific use case would be better.

Gary


> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Gary Gregory]

On Tue, Apr 18, 2017 at 2:31 AM, sebb  wrote:

> On 18 April 2017 at 07:36, Gary Gregory  wrote:
> > Hi All:
> >
> > We have two styles for the new concurrency annotations in master:
> >
> > (1) JCIP
> > (2) Apache HttpComponents Core
>
> Where are those located?
>

(1) JCIP inspired:
org.apache.commons.lang3.concurrent.annotation.GuardedBy
org.apache.commons.lang3.concurrent.annotation.Immutable
org.apache.commons.lang3.concurrent.annotation.NotThreadSafe
org.apache.commons.lang3.concurrent.annotation.ThreadSafe

(2) Apache HttpComponents Core
org.apache.commons.lang3.concurrent.annotation.Contract
org.apache.commons.lang3.concurrent.annotation.ThreadingBehavior

I think it is worth keeping GuardedBy no matter what.

Gary

I think it's important to be clear exactly what is being discussed.
>
> What about the annotations, Contract and the associated enum
> ThreadingBehavior?
>
> > I would like to delete (1) in favor of (2). I started this discussion
> > inappropriately on a VOTE thread, sorry for the redo.
> >
> > Then we can proceed with another release candidate.
> >
> > Also at issue is where the new annotations belong
> >
> > (1) org.apache.commons.lang3.concurrent.annotation (current)
> > (2) org.apache.commons.lang3.annotation (my preferred location)
> >
> > Thoughts?
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> >
> >  1617290459>
> > JUnit in Action, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> >
> >  1935182021>
> > Spring Batch in Action
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Emmanuel Bourg]

Le 18/04/2017 à 08:36, Gary Gregory a écrit :

> Thoughts?

I think I tend to prefer the JCIP style. ThreadingBehavior conflates the
notions of thread safety and immutability and intuitively I'd keep them
separate, even if they are often closely related. An object could be
immutable and not thread safe because it operates on an external
resource that doesn't work concurrently.

Emmanuel Bourg


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

Re: [lang] new concurrency annotations

[sebb]

On 18 April 2017 at 07:36, Gary Gregory  wrote:
> Hi All:
>
> We have two styles for the new concurrency annotations in master:
>
> (1) JCIP
> (2) Apache HttpComponents Core

Where are those located?
I think it's important to be clear exactly what is being discussed.

What about the annotations, Contract and the associated enum ThreadingBehavior?

> I would like to delete (1) in favor of (2). I started this discussion
> inappropriately on a VOTE thread, sorry for the redo.
>
> Then we can proceed with another release candidate.
>
> Also at issue is where the new annotations belong
>
> (1) org.apache.commons.lang3.concurrent.annotation (current)
> (2) org.apache.commons.lang3.annotation (my preferred location)
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
>
> 
> JUnit in Action, Second Edition
> 
>
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [lang] new concurrency annotations

[Jörg Schaible]

Benedikt Ritter wrote:

> Hi,
> 
>> Am 18.04.2017 um 08:36 schrieb Gary Gregory :
>> 
>> Hi All:
>> 
>> We have two styles for the new concurrency annotations in master:
>> 
>> (1) JCIP
>> (2) Apache HttpComponents Core
>> 
>> I would like to delete (1) in favor of (2). I started this discussion
>> inappropriately on a VOTE thread, sorry for the redo.
> 
> Yes, this makes sense in the light of the reason you gave on the other
> thread.
> 
>> 
>> Then we can proceed with another release candidate.
>> 
>> Also at issue is where the new annotations belong
>> 
>> (1) org.apache.commons.lang3.concurrent.annotation (current)
>> (2) org.apache.commons.lang3.annotation (my preferred location)
> 
> What about (3) org.apache.commons.lang3.concurrent ?
> 
> I don’t think it’s good style to package things by their technical nature.
> Why do annotations deserve their own package? Why don’t we have
> o.a.c.l.enum/abstractclass/expection then? From my PoV its easier to
> understand if things are packaged by their domain. For this reason I’d
> argue @Contract belongs to o.a.c.l.concurrent (without sub package)

+1

- Jörg


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

Re: [lang] new concurrency annotations

[Gary Gregory]

On Mon, Apr 17, 2017 at 11:55 PM, Benedikt Ritter 
wrote:

> Hi,
>
> > Am 18.04.2017 um 08:36 schrieb Gary Gregory :
> >
> > Hi All:
> >
> > We have two styles for the new concurrency annotations in master:
> >
> > (1) JCIP
> > (2) Apache HttpComponents Core
> >
> > I would like to delete (1) in favor of (2). I started this discussion
> > inappropriately on a VOTE thread, sorry for the redo.
>
> Yes, this makes sense in the light of the reason you gave on the other
> thread.
>
> >
> > Then we can proceed with another release candidate.
> >
> > Also at issue is where the new annotations belong
> >
> > (1) org.apache.commons.lang3.concurrent.annotation (current)
> > (2) org.apache.commons.lang3.annotation (my preferred location)
>
> What about (3) org.apache.commons.lang3.concurrent ?
>
> I don’t think it’s good style to package things by their technical nature.
> Why do annotations deserve their own package? Why don’t we have
> o.a.c.l.enum/abstractclass/expection then? From my PoV its easier to
> understand if things are packaged by their domain. For this reason I’d
> argue @Contract belongs to o.a.c.l.concurrent (without sub package)
>

That's fine by me.

Gary


>
> Benedikt
>
> >
> > Thoughts?
> >
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
> >
> >  1617290459>
> > JUnit in Action, Second Edition
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
> >
> >  1935182021>
> > Spring Batch in Action
> >  tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> >  1935182951>
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] new concurrency annotations

[Benedikt Ritter]

Hi,

> Am 18.04.2017 um 08:36 schrieb Gary Gregory :
> 
> Hi All:
> 
> We have two styles for the new concurrency annotations in master:
> 
> (1) JCIP
> (2) Apache HttpComponents Core
> 
> I would like to delete (1) in favor of (2). I started this discussion
> inappropriately on a VOTE thread, sorry for the redo.

Yes, this makes sense in the light of the reason you gave on the other thread.

> 
> Then we can proceed with another release candidate.
> 
> Also at issue is where the new annotations belong
> 
> (1) org.apache.commons.lang3.concurrent.annotation (current)
> (2) org.apache.commons.lang3.annotation (my preferred location)

What about (3) org.apache.commons.lang3.concurrent ?

I don’t think it’s good style to package things by their technical nature. Why 
do annotations deserve their own package? Why don’t we have 
o.a.c.l.enum/abstractclass/expection then? From my PoV its easier to understand 
if things are packaged by their domain. For this reason I’d argue @Contract 
belongs to o.a.c.l.concurrent (without sub package)

Benedikt

> 
> Thoughts?
> 
> Gary
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> 
> 
> JUnit in Action, Second Edition
> 
> 
> 
> Spring Batch in Action
> 
> 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory


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

[lang] new concurrency annotations

[Gary Gregory]

Hi All:

We have two styles for the new concurrency annotations in master:

(1) JCIP
(2) Apache HttpComponents Core

I would like to delete (1) in favor of (2). I started this discussion
inappropriately on a VOTE thread, sorry for the redo.

Then we can proceed with another release candidate.

Also at issue is where the new annotations belong

(1) org.apache.commons.lang3.concurrent.annotation (current)
(2) org.apache.commons.lang3.annotation (my preferred location)

Thoughts?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory