I vote mainly for the use of
- Custom annotations
- Put the information right into the JavaDoc is also useful but I think
that maybe some indication on the name of the class might be a good idea too
On Sat, Nov 19, 2016 at 6:52 AM, Benedikt Ritter wrote:
> Hi,
>
> after my presentation about Ap
On Tue, Nov 22, 2016 at 4:08 PM, Gary Gregory
wrote:
> On Tue, Nov 22, 2016 at 4:04 PM, Gary Gregory
> wrote:
>
>> An interesting question is whether we should provide a copy of the
>> annotations scoped as RUNTIME, which was the original way the code was
>> published out of the JCIP book.
>>
>>
On Tue, Nov 22, 2016 at 4:04 PM, Gary Gregory
wrote:
> An interesting question is whether we should provide a copy of the
> annotations scoped as RUNTIME, which was the original way the code was
> published out of the JCIP book.
>
> For our use case within Commons, we want a CLASS or SOURCE level
An interesting question is whether we should provide a copy of the
annotations scoped as RUNTIME, which was the original way the code was
published out of the JCIP book.
For our use case within Commons, we want a CLASS or SOURCE level
dependency. We do not want RUNTIME because we do not want a har
It would if the Google version or ours is signed. It also would be a
problem if we used a different retention level from Google's.
Maybe using our own in o.a.c.lang3 would be less confusing all around.
Gary
On Tue, Nov 22, 2016 at 2:15 PM, Matt Sicker wrote:
> Would packaging them in the JSR p
Would packaging them in the JSR package name inside commons lang cause
classpath issues if you include the google copy?
On 22 November 2016 at 15:53, Gary Gregory wrote:
> Should we:
>
> - package these (three) annotations per the JSR package name, or,
> - in o.a.c.lang3, or,
> - should we depen
Should we:
- package these (three) annotations per the JSR package name, or,
- in o.a.c.lang3, or,
- should we depend on a jar like
https://search.maven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C3.0.1%7Cjar
?
Gary
On Tue, Nov 22, 2016 at 1:47 PM, Matt Sicker wrote:
> It's at
It's at least pretty standard (being a JSR and all), plus no runtime
dependency, I don't see why not!
On 22 November 2016 at 15:36, Gary Gregory wrote:
> Maybe we could start with adding these three annotations to [lang] with
> Class retention which does not create a runtime dependency. Then we
Maybe we could start with adding these three annotations to [lang] with
Class retention which does not create a runtime dependency. Then we can use
them all over Commons.
WDYT?
Gary
On Tue, Nov 22, 2016 at 11:39 AM, Benedikt Ritter
wrote:
> Hello,
>
> Gary Gregory schrieb am So., 20. Nov. 201
Hello,
Gary Gregory schrieb am So., 20. Nov. 2016 um
16:50 Uhr:
> Let's recognize that these annotations can give you a false sense of
> confidence, you still should read at least the docs and probably the code
> if you REALLY care about thread safety.
>
I thought about this again today on my w
Let's recognize that these annotations can give you a false sense of
confidence, you still should read at least the docs and probably the code
if you REALLY care about thread safety.
There will be mistakes in documentation where the wrong or contradictory
annotation will split in and/or will be ou
+1 to adding this information to the class javadoc
Am 19.11.2016 um 12:52 schrieb Benedikt Ritter:
Hi,
after my presentation about Apache Commons, there where some comments about
[lang]. One person said, that it is hard to find out whether our classes
are threadsafe or not. He would like to see
Custom annotations seems like the clearest way.
Gary
On Nov 19, 2016 3:52 AM, "Benedikt Ritter" wrote:
> Hi,
>
> after my presentation about Apache Commons, there where some comments about
> [lang]. One person said, that it is hard to find out whether our classes
> are threadsafe or not. He wou
Hi,
after my presentation about Apache Commons, there where some comments about
[lang]. One person said, that it is hard to find out whether our classes
are threadsafe or not. He would like to see that better documented.
I know that sebb has done some work in that direction, but as far as I know
14 matches
Mail list logo
