Oh that's a pretty decent advantage there actually.
On 29 November 2016 at 22:07, Gary Gregory wrote:
> On Tue, Nov 29, 2016 at 8:04 PM, Matt Sicker wrote:
>
> > That's pretty neat. So it looks like two competing styles of annotations
> > here would be separate annotations for each concern, a s
On Tue, Nov 29, 2016 at 8:04 PM, Matt Sicker wrote:
> That's pretty neat. So it looks like two competing styles of annotations
> here would be separate annotations for each concern, a single annotation
> with an enum, or even separate annotations with boolean values or enums
> (though that gets a
That's pretty neat. So it looks like two competing styles of annotations
here would be separate annotations for each concern, a single annotation
with an enum, or even separate annotations with boolean values or enums
(though that gets a little more complex come to think of it).
If only the JDK ha
And an example:
/**
* HTTP/2 compatible extension of {@link RequestConnControl}.
*
* @since 5.0
*/
@Contract(threading = ThreadingBehavior.IMMUTABLE)
public class H2RequestConnControl extends RequestConnControl {
...
Gary
On Tue, Nov 29, 2016 at 6:40 PM, Gary Gregory
wrote:
> FYI, this is
FYI, this is how we're going to do it in HttpComponents 5:
https://svn.apache.org/repos/asf/httpcomponents/httpcore/trunk/httpcore5/src/main/java/org/apache/hc/core5/annotation/ThreadingBehavior.java
Gary
On Tue, Nov 29, 2016 at 2:20 PM, Gary Gregory
wrote:
> On Tue, Nov 29, 2016 at 1:59 PM, Be
On Tue, Nov 29, 2016 at 1:59 PM, Benedikt Ritter wrote:
> I agree with Oliver. I don't think we have consensus about if and how we
> want to implement this. Does it even make sense to try to document this?
> What value does such a documentation have, when it is wrong 50% of the
> time? I just sum
I agree with Oliver. I don't think we have consensus about if and how we
want to implement this. Does it even make sense to try to document this?
What value does such a documentation have, when it is wrong 50% of the
time? I just sumed up the feedback I got from one (!) user at the
conference. I th
On Tue, Nov 29, 2016 at 1:12 PM, Oliver Heger
wrote:
>
>
> Am 28.11.2016 um 22:28 schrieb Gary Gregory:
> > WRT licensing, I re-implemented the annotations in git master. Notice
> that
> > all Javadocs are different and much simpler for now. Feel free to write
> > more.
>
> As the length of this
Am 28.11.2016 um 22:28 schrieb Gary Gregory:
> WRT licensing, I re-implemented the annotations in git master. Notice that
> all Javadocs are different and much simpler for now. Feel free to write
> more.
As the length of this thread shows, using annotations for the purpose of
documenting thread-
WRT licensing, I re-implemented the annotations in git master. Notice that
all Javadocs are different and much simpler for now. Feel free to write
more.
Gary
On Mon, Nov 28, 2016 at 12:55 PM, Gary Gregory
wrote:
> On Mon, Nov 28, 2016 at 12:18 PM, Matt Benson
> wrote:
>
>> I hoped to stay out
On Mon, Nov 28, 2016 at 12:18 PM, Matt Benson wrote:
> I hoped to stay out of this. :) Points:
>
> * "provided" scope is another Maven mechanism that compiles against a
> given dependency but does not pull the dependency in as a runtime
> dependency. I personally prefer it to marking a dependency
I hoped to stay out of this. :) Points:
* "provided" scope is another Maven mechanism that compiles against a
given dependency but does not pull the dependency in as a runtime
dependency. I personally prefer it to marking a dependency optional.
* For annotations with only classfile retention, a fu
Groovy had to change the license of its documentation from CC-A 3.0 to
the Apache License during incubation:
https://issues.apache.org/jira/browse/LEGAL-167
http://markmail.org/message/2e7tehlwtpx625q4
https://issues.apache.org/jira/browse/GROOVY-7470
So I guess Commons is probably not allowed
On Mon, Nov 28, 2016 at 7:15 AM, Jochen Wiedmann
wrote:
> On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote:
>
> > The code would not run without the JCIP jar.
>
> Are there licensing issues regarding that jar?
>
Hm, according to https://www.apache.org/legal/resolved.html, the license
"Creative Commo
On 28 November 2016 at 15:15, Jochen Wiedmann wrote:
> On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote:
>
>> The code would not run without the JCIP jar.
>
> Are there licensing issues regarding that jar?
I think there were, but regardless, the jar serves no runtime purpose
as far as HC (or Commons)
On Mon, Nov 28, 2016 at 4:13 PM, sebb wrote:
> Either you have to allow a separate release cycle for that jar.
> Or you have to release a new version of the jar with every LANG release.
> The content will likely be identical for each one unless the Javadoc is
> tweaked.
I'd strongly recommend
On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote:
> The code would not run without the JCIP jar.
Are there licensing issues regarding that jar?
Jochen
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300
On 28 November 2016 at 13:12, Jochen Wiedmann wrote:
> On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote:
>
>> No, I'm suggesting that the annotations become an independent Commons
>> component.
>> If we don't want these used outside Commons (probably a good idea)
>> then we can make this clear throu
On 28 November 2016 at 13:10, Jochen Wiedmann wrote:
> On Mon, Nov 28, 2016 at 12:03 PM, sebb wrote:
>> Yes, we started with the ones from JCIP, but these had runtime
>> retention, which caused issues.
>
> What kind of problems, if I may ask?
The code would not run without the JCIP jar.
> Thank
On Mon, 28 Nov 2016 14:12:48 +0100, Jochen Wiedmann wrote:
On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote:
No, I'm suggesting that the annotations become an independent
Commons component.
If we don't want these used outside Commons (probably a good idea)
then we can make this clear through Java
On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote:
> No, I'm suggesting that the annotations become an independent Commons
> component.
> If we don't want these used outside Commons (probably a good idea)
> then we can make this clear through Javadoc and package naming etc.
>
> The alternative is to
On Mon, Nov 28, 2016 at 12:03 PM, sebb wrote:
> Yes, we started with the ones from JCIP, but these had runtime
> retention, which caused issues.
What kind of problems, if I may ask?
Thanks,
Jochen
-
To unsubscribe, e-mail: dev
On 28 November 2016 at 01:55, Gary Gregory wrote:
> Are you suggesting [lang] becomes a multi-module project?
No, I'm suggesting that the annotations become an independent Commons component.
If we don't want these used outside Commons (probably a good idea)
then we can make this clear through Jav
Yes, we started with the ones from JCIP, but these had runtime
retention, which caused issues.
I e-mailed JCIP asking if the retention could be changed, but no joy.
We therefore created our own from elsewhere.
Not sure why we eventually dropped them.
On 28 November 2016 at 04:06, Matt Sicker wro
Ah, ok, what I have in there now is in our own package.
Gary
On Nov 27, 2016 8:06 PM, "Matt Sicker" wrote:
> Well, HttpClient used to have the same (or similar) thread safety
> annotations for documentation purposes, and I think they were just custom
> annotations and not the javax ones.
>
> On
Well, HttpClient used to have the same (or similar) thread safety
annotations for documentation purposes, and I think they were just custom
annotations and not the javax ones.
On 27 November 2016 at 20:50, Gary Gregory wrote:
> On Nov 27, 2016 6:46 PM, "Matt Sicker" wrote:
> >
> > I'd be in fav
On Nov 27, 2016 6:46 PM, "Matt Sicker" wrote:
>
> I'd be in favor of just including this as an internal annotation similar
to
> how it's done in HttpClient.
What does that mean specifically? FWIW, I think those annotations might be
gone in the current svn trunk.
Gary
>
> On 27 November 2016 at 2
Oh, and JSR 305 does not actually specify any concurrency annotations.
Gary
On Nov 27, 2016 6:46 PM, "Matt Sicker" wrote:
> I'd be in favor of just including this as an internal annotation similar to
> how it's done in HttpClient.
>
> On 27 November 2016 at 20:44, Gary Gregory wrote:
>
> > I d
Also note that the JCIP code uses its own package AND declares the
annotations with the RUNTIME retention policy.
Gary
On Nov 27, 2016 6:39 PM, "Matt Sicker" wrote:
> If you're going to share the annotations between projects, why not use a
> JSR package for it like the google one? I thought the
I'd be in favor of just including this as an internal annotation similar to
how it's done in HttpClient.
On 27 November 2016 at 20:44, Gary Gregory wrote:
> I do not think we should use an official Java package because the JSR 305
> page says "The Executive Committee voted to list this JSR as do
I do not think we should use an official Java package because the JSR 305
page says "The Executive Committee voted to list this JSR as dormant in May
2012."
Gary
On Nov 27, 2016 6:39 PM, "Matt Sicker" wrote:
> If you're going to share the annotations between projects, why not use a
> JSR packag
If you're going to share the annotations between projects, why not use a
JSR package for it like the google one? I thought the idea of embedding the
annotations in [lang] was to prevent the need for the dependency and to use
it internally, not as a public annotation for other projects to use.
On 2
Are you suggesting [lang] becomes a multi-module project?
Gary
On Nov 27, 2016 5:01 PM, "sebb" wrote:
> On 28 November 2016 at 00:11, Gary Gregory wrote:
> > On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote:
> >
> >> On 27 November 2016 at 23:51, Gary Gregory
> wrote:
> >> > On Sun, Nov 27, 2016
On 28 November 2016 at 00:11, Gary Gregory wrote:
> On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote:
>
>> On 27 November 2016 at 23:51, Gary Gregory wrote:
>> > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
>> >
>> >> On 27 November 2016 at 22:31, Gary Gregory
>> wrote:
>> >> > On Sun, Nov 27, 2016
On 28 November 2016 at 10:51, Gary Gregory wrote:
> On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
>
>> On 27 November 2016 at 22:31, Gary Gregory wrote:
>> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
>> >
>> >> On 27 November 2016 at 22:03, Gary Gregory
>> wrote:
>> >> > These annotations ar
On Sun, Nov 27, 2016 at 4:09 PM, sebb wrote:
> On 27 November 2016 at 23:51, Gary Gregory wrote:
> > On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
> >
> >> On 27 November 2016 at 22:31, Gary Gregory
> wrote:
> >> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
> >> >
> >> >> On 27 November 2016
On 27 November 2016 at 23:51, Gary Gregory wrote:
> On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
>
>> On 27 November 2016 at 22:31, Gary Gregory wrote:
>> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
>> >
>> >> On 27 November 2016 at 22:03, Gary Gregory
>> wrote:
>> >> > These annotations ar
On Sun, Nov 27, 2016 at 3:51 PM, Gary Gregory
wrote:
> On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
>
>> On 27 November 2016 at 22:31, Gary Gregory
>> wrote:
>> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
>> >
>> >> On 27 November 2016 at 22:03, Gary Gregory
>> wrote:
>> >> > These annotat
On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
> On 27 November 2016 at 22:31, Gary Gregory wrote:
> > On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
> >
> >> On 27 November 2016 at 22:03, Gary Gregory
> wrote:
> >> > These annotations are the SAME as have been published all over the
> place,
> >>
On 28 November 2016 at 10:41, sebb wrote:
> On 27 November 2016 at 22:31, Gary Gregory wrote:
>> It is _because_ they are NOT built-in the language or JRE that we are
>> proposing they belong in [lang].
>>
>> Since we are providing the annotation with CLASS retention only
>> (initially), there is
Please see https://issues.apache.org/jira/browse/LANG-1291 and git master
main and unit tests. It's pretty neat that you can only have a compile-time
dependency and not a runtime dependency as the unit tests show.
Gary
On Sun, Nov 27, 2016 at 3:41 PM, sebb wrote:
> On 27 November 2016 at 22:31,
On 27 November 2016 at 22:31, Gary Gregory wrote:
> On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
>
>> On 27 November 2016 at 22:03, Gary Gregory wrote:
>> > These annotations are the SAME as have been published all over the place,
>> > so I do not think we need a PR for review. Reviewing the cod
On Sun, Nov 27, 2016 at 2:14 PM, sebb wrote:
> On 27 November 2016 at 22:03, Gary Gregory wrote:
> > These annotations are the SAME as have been published all over the place,
> > so I do not think we need a PR for review. Reviewing the code in the repo
> > should be enough, but I'm not sure _wha
On 27 November 2016 at 22:03, Gary Gregory wrote:
> These annotations are the SAME as have been published all over the place,
> so I do not think we need a PR for review. Reviewing the code in the repo
> should be enough, but I'm not sure _what_ there is to review really. I've
> already posted a l
These annotations are the SAME as have been published all over the place,
so I do not think we need a PR for review. Reviewing the code in the repo
should be enough, but I'm not sure _what_ there is to review really. I've
already posted a link to the sources (a pastebin link). I'll create a Jira
of
Hi,
Gary Gregory schrieb am So., 27. Nov. 2016 um
21:01 Uhr:
> So let's start with the CLASS retention annotations first. I'll commit
> later today.
>
Maybe create a GitHub PR so people can have a look before it goes to master?
Benedikt
>
> Gary
>
> On Nov 27, 2016 9:50 AM, "Matt Sicker" wr
So let's start with the CLASS retention annotations first. I'll commit
later today.
Gary
On Nov 27, 2016 9:50 AM, "Matt Sicker" wrote:
> I feel like documenting thread safety in such a low level, widely used
> library like [lang] is a great idea. Whether it uses annotations, javadocs,
> or some
My view is that it might be challenging to do and keep the information
accurate over time, but that this is a worthy goal nonetheless. Having the
annotations around will allow for anyone to do this in a standard way.
Coming up with a Javadoc only way to do this is too much of a pain IMO.
Gary
On
I feel like documenting thread safety in such a low level, widely used
library like [lang] is a great idea. Whether it uses annotations, javadocs,
or some sort of informal javadoc comments isn't too big a deal to me, but
providing some guarantees of thread safety or lack thereof would be
invaluable
I thought we decided to abstain from documenting thread safety since it
would get outdated quickly anyway.
Gary Gregory schrieb am So., 27. Nov. 2016 um
09:11 Uhr:
> But if we then want a runtime version we had an odd packaging with CLASS
> retention in .concurrent. and RUNTIME in .concurrent.ru
But if we then want a runtime version we had an odd packaging with CLASS
retention in .concurrent. and RUNTIME in .concurrent.runtime.
I might be in YAGNI territory here...
Gary
On Sat, Nov 26, 2016 at 10:07 PM, Matt Sicker wrote:
> I think adding the additional clazz/runtime package would be
I think adding the additional clazz/runtime package would be a little
overkill if you only include one packaging option for now.
On 27 November 2016 at 00:04, Gary Gregory wrote:
> On Nov 26, 2016 8:40 PM, "Matt Sicker" wrote:
> >
> > I can think of a couple use cases for runtime retention for
On Nov 26, 2016 8:40 PM, "Matt Sicker" wrote:
>
> I can think of a couple use cases for runtime retention for thread safety
> annotations, but they're not specific to commons lang.
>
> 1. A framework could choose what type of data structure or algorithm to
use
> at runtime based on the presence of
I can think of a couple use cases for runtime retention for thread safety
annotations, but they're not specific to commons lang.
1. A framework could choose what type of data structure or algorithm to use
at runtime based on the presence of which thread safety annotation is on.
Same for mutability
On Sat, Nov 26, 2016 at 3:54 PM, sebb wrote:
> On 26 November 2016 at 19:25, Gary Gregory wrote:
> > On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add
> the
> > "classic" four javax.annotation.concurrent annotations to two packages
> > (.clazz and .runtime) in Commons Lang fo
On 26 November 2016 at 19:25, Gary Gregory wrote:
> On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add the
> "classic" four javax.annotation.concurrent annotations to two packages
> (.clazz and .runtime) in Commons Lang for CLASS and RUNTIME retentions.
>
> You'd use the CLASS v
On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add the
"classic" four javax.annotation.concurrent annotations to two packages
(.clazz and .runtime) in Commons Lang for CLASS and RUNTIME retentions.
You'd use the CLASS version to avoid a hard dependency on [lang]. RUNTIME
to keep
57 matches
Mail list logo