Quoting Effective Java 2nd edition, Item 70: Document thread safety:
"
How a class behaves when its instances or static methods are subjected
to concurrent use is an important part of the contract the class makes
with its clients. If you don’t document this facet of a class’s
behavior, programmers who use the class will be forced to make
assumptions. If those assumptions are wrong, the resulting program may
perform insufficient synchronization (Item 66) or excessive
synchronization (Item 67). In either case, serious errors can result. [...]
To summarize, every class should clearly document its thread safety
properties with a carefully worded prose description or a thread safety
annotation. The synchronized modifier plays no part in this
documentation. Conditionally thread-safe classes must document which
method invocation sequences require external synchronization, and which
lock to acquire when executing these sequences. If you write an
unconditionally thread-safe class, consider using a private lock object
in place of synchronized methods. This protects you against
synchronization interference by clients and subclasses and gives you the
flexibility toadopt a more sophisticated approach to concurrency control
in a later release.
"
Filed
https://java.net/jira/browse/JAX_RS_SPEC-490
Gili
On 07/11/2014 12:35 PM, Robert DiFalco wrote:
> My vote would be for NOT being thread safe.
>
> On Fri, Nov 7, 2014 at 9:13 AM, Marek Potociar
> <marek.potociar_at_oracle.com <mailto:marek.potociar_at_oracle.com>> wrote:
>
> It’s actually JAX-RS spec that should clarify this. Please file a
> new issue <https://java.net/jira/browse/JAX_RS_SPEC> if you care.
>
> Cheers,
> Marek
>
>> On 28 Oct 2014, at 15:04, cowwoc <cowwoc_at_bbs.darktech.org
>> <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>>
>> I'm saying that the Jersey team needs to document thread-safety
>> if it exist (and yes, I believe this code really is thread-safe).
>>
>> Gili
>>
>> On 28/10/2014 9:53 AM, Rodrigo Uchôa wrote:
>>> So we can make no assumptions about the thread-safety of the
>>> Client class? Back to square one then. Pooling is the right
>>> approach.
>>>
>>> On Tue, Oct 28, 2014 at 11:44 AM, cowwoc
>>> <cowwoc_at_bbs.darktech.org <mailto:cowwoc_at_bbs.darktech.org>> wrote:
>>>
>>> The exact opposite is true.
>>>
>>> The Javadoc/specification is a contract. Anything that is
>>> not explicitly listed is an implementation detail that may
>>> change at any time.
>>>
>>> Gili
>>>
>>>
>>> On 28/10/2014 8:49 AM, Markus Karg wrote:
>>>>
>>>> Don’t understand your critics. Isn’t it typical in all
>>>> JavaDocs to only warn about MISSING thread-safety?
>>>>
>>>>
>>>> *Von:*Rodrigo Uchôa [mailto:rodrigo.uchoa_at_gmail.com]
>>>> *Gesendet:* Dienstag, 28. Oktober 2014 13:47
>>>> *An:* users_at_jersey.java.net <mailto:users_at_jersey.java.net>
>>>> *Betreff:* [Jersey] Re: Pool for javax.ws.rs.client.Client
>>>> objects?
>>>>
>>>>
>>>> I just find it really weird that if Client objects should
>>>> be implemented in a thread-safe way, this is not explicit
>>>> in the javadocs. :) But it does make things a lot easier if
>>>> it is.
>>>>
>>>>
>>>> On Tue, Oct 28, 2014 at 8:31 AM, Markus Karg
>>>> <karg_at_quipsy.de <mailto:karg_at_quipsy.de>> wrote:
>>>>
>>>> FYI: Reuse of objects can also be done on the level of
>>>> targets and invocation templates, a.k.a. Invocation class:
>>>> You can invoke it several times using different values (see
>>>>
>>>> http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property(java.lang.String,
>>>> java.lang.Object)
>>>> <http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#property%28java.lang.String,%20java.lang.Object%29>
>>>> and
>>>> http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#invoke(java.lang.Class)
>>>> <http://docs.oracle.com/javaee/7/api/javax/ws/rs/client/Invocation.html#invoke%28java.lang.Class%29>).
>>>>
>>>>
>>>> *Von:*Colin Vipurs [mailto:zodiaczx6_at_gmail.com
>>>> <mailto:zodiaczx6_at_gmail.com>]
>>>> *Gesendet:* Dienstag, 28. Oktober 2014 10:44
>>>> *An:* users_at_jersey.java.net <mailto:users_at_jersey.java.net>
>>>> *Betreff:* [Jersey] Re: Pool for javax.ws.rs.client.Client
>>>> objects?
>>>>
>>>>
>>>> This is exactly what we do across all our services. You
>>>> should notice quite the performance improvement switching
>>>> to this as well
>>>>
>>>>
>>>> On Tue, Oct 28, 2014 at 9:10 AM, Markus Karg
>>>> <karg_at_quipsy.de <mailto:karg_at_quipsy.de>> wrote:
>>>>
>>>> Did you find any official documentation which says that you
>>>> must not use one single client concurrently by different
>>>> threads? If not, why not just using a single instance?
>>>>
>>>>
>>>> *Von:*Rodrigo Uchôa [mailto:rodrigo.uchoa_at_gmail.com
>>>> <mailto:rodrigo.uchoa_at_gmail.com>]
>>>> *Gesendet:* Dienstag, 28. Oktober 2014 00:12
>>>> *An:* users_at_jersey.java.net <mailto:users_at_jersey.java.net>
>>>> *Betreff:* [Jersey] Pool for javax.ws.rs.client.Client objects?
>>>>
>>>>
>>>> Hi guys!
>>>>
>>>>
>>>> I have a client web application that uses the Client API to
>>>> make REST calls to a REST business layer.
>>>>
>>>>
>>>> The javax.ws.rs.client.Client docs clearly states that
>>>> Client objects are expensive to create and dispose, and
>>>> only a small number of them should be created, which makes
>>>> me think they should be pooled somehow.
>>>>
>>>>
>>>> Our initial thought was to instantiate and then close every
>>>> Client object we use, making code like this:
>>>>
>>>>
>>>> public void doSomething() {
>>>>
>>>> Client client = ClientBuilder.newClient();
>>>>
>>>> //do a bunch of stuff here
>>>>
>>>> client.close();
>>>>
>>>> }
>>>>
>>>>
>>>> Every method that needs to invoke REST services are coded
>>>> like the example above. That means every time a client web
>>>> request comes in, a new Client object is created and then
>>>> closed. The exact opposite of what the docs advises us to do.
>>>>
>>>>
>>>> How should we implement a pool of Client objects in this
>>>> scenario? Is there a common solution?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Rodrigo Uchoa.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Maybe she awoke to see the roommate's boyfriend swinging
>>>> from the chandelier wearing a boar's head.
>>>>
>>>> Something which you, I, and everyone else would call
>>>> "Tuesday", of course.
>>>>
>>>>
>>>
>>>
>>
>
>