What about the question , why Entity was not defined as an interface, but a
class?
We had a slightly similar discussion in another thread around JSR 310 final
types like Duration, LocalDate, etc. but despite the Spec Lead having a
strong favor of final concrete classes over interfaces (while the mentioned
Bloch says otherwise in some of his books;-) those who helped him as Co
Spec Leads integrating it into Java 8 in the end declared interfaces around
those final classes, so you may use e.g. Temporal, etc. and should be able
to mock them in tests, too.
Werner
On Thu, Aug 27, 2015 at 11:15 AM, <users-request_at_jax-rs-spec.java.net>
wrote:
> Table of contents:
>
> 1. [jax-rs-spec users] Re: Why is "Entity" class final - Marek Potociar <
> marek.potociar_at_oracle.com>
> 2. [jax-rs-spec users] Re: Why is "Entity" class final - Qingtian Wang <
> wqt.net_at_gmail.com>
>
>
>
> ---------- Forwarded message ----------
> From: Marek Potociar <marek.potociar_at_oracle.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Wed, 26 Aug 2015 16:33:48 +0200
> Subject: [jax-rs-spec users] Re: Why is "Entity" class final
> I’m sorry, but I do not have any intention to consider loosening of the
> API contract just to support test mocking.
>
> Again, I’m sorry, but no.
> Marek
>
> On 21 Aug 2015, at 18:18, Qingtian Wang <wqt.net_at_gmail.com> wrote:
>
> Actually, there may be a compromise here:
>
> All I want is for the "final" to be removed. That way, I still can not
> subclass it given the private constructors and all that - that seams to
> address your concern of me doing "bad things" by subclassing. However, with
> the "final" gone, I will be able to "mock" to, using some mocking tool,
> like this:
>
> Entity mockEntity = mock(Entity.class);
> when(mockEntity.getEntity()).thenReturn(someMuliPartObjectSetupForTestingPurpose);
> // this is only possible without the "final" mark
>
> Again, I still can't subclass it even without the "final" mark; but i will
> able to "mock" it.
>
>
>
> On Fri, Aug 21, 2015 at 10:43 AM Qingtian Wang <wqt.net_at_gmail.com> wrote:
>
>> The point here is hard to "mock" (in which you'd set up
>> verify/check/assert), not hard to "stub/generate/instantiate"(that is easy
>> either with the current static factory methods, or with Matchers such as
>> the one used in my example).
>>
>> As per the analogy to String, that is a bit far fetched IMO.
>> Conceptually, String's representing data structure is simpler - mainly
>> just its "value", whereas Entity includes data structure that encapsulates
>> HTTP constructs which can be rather involved. Technically, Entity has a
>> long way to go before getting to String's status: at least it should have
>> things like "equalIgnoreAnnotations()", "equalIgnoreLocales()", and all
>> kinds of constructors like String has, in addition to just the static
>> factory methods currently.
>>
>> Bloch talks about the non-extendable drawback of having only static
>> factory methods. IMO this case really falls into the drawback category
>> instead of "blessing in disguise" - i am not trying to subclass and change
>> Entity's behavior in my source code; rather i am just trying "mock" it such
>> that i can test i am instantiating the Entity correctly, ex. by passing in
>> the right data as the right parameters for the multiPart contained in the
>> Entity.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Aug 21, 2015, 04:19 Marek Potociar <marek.potociar_at_oracle.com>
>> wrote:
>>
>>> You can come up with an entity generating code. Esp. for Entity it
>>> should be simple to implement. The arguments that you provide do not
>>> justify your requirement to make Entity non-final. You could as well argue
>>> for making String non-final… It just makes little sense IMO as problems
>>> would greatly outweigh any potential benefits.
>>>
>>> Marek
>>>
>>> > On 20 Aug 2015, at 21:49, wqt.net_at_gmail.com wrote:
>>> >
>>> > Another clarification is that I have mixed up the terms of "stub" and
>>> > "mock" from the get go of my question: I guess what i am wanting to do
>>> > here is to "mock" (with check/verify/assert...) the Entity class, not
>>> > just to "stub" it.
>>>
>>>
>
>
> ---------- Forwarded message ----------
> From: Qingtian Wang <wqt.net_at_gmail.com>
> To: users_at_jax-rs-spec.java.net
> Cc:
> Date: Thu, 27 Aug 2015 03:04:26 +0000
> Subject: [jax-rs-spec users] Re: Why is "Entity" class final
> Mr. Potociar,
>
> Thanks again for the reply. I think I can understand that from your point
> of view....
>
> If you could humor me a bit further on this... What is the thoughts of
> design here that Entity is not defined as an interface, but a class?
>
>
>
> On Wed, Aug 26, 2015 at 9:35 AM Marek Potociar <marek.potociar_at_oracle.com>
> wrote:
>
>> I’m sorry, but I do not have any intention to consider loosening of the
>> API contract just to support test mocking.
>>
>> Again, I’m sorry, but no.
>> Marek
>>
>> On 21 Aug 2015, at 18:18, Qingtian Wang <wqt.net_at_gmail.com> wrote:
>>
>> Actually, there may be a compromise here:
>>
>> All I want is for the "final" to be removed. That way, I still can not
>> subclass it given the private constructors and all that - that seams to
>> address your concern of me doing "bad things" by subclassing. However, with
>> the "final" gone, I will be able to "mock" to, using some mocking tool,
>> like this:
>>
>> Entity mockEntity = mock(Entity.class);
>> when(mockEntity.getEntity()).thenReturn(someMuliPartObjectSetupForTestingPurpose);
>> // this is only possible without the "final" mark
>>
>> Again, I still can't subclass it even without the "final" mark; but i
>> will able to "mock" it.
>>
>>
>>
>> On Fri, Aug 21, 2015 at 10:43 AM Qingtian Wang <wqt.net_at_gmail.com> wrote:
>>
>>> The point here is hard to "mock" (in which you'd set up
>>> verify/check/assert), not hard to "stub/generate/instantiate"(that is easy
>>> either with the current static factory methods, or with Matchers such as
>>> the one used in my example).
>>>
>>> As per the analogy to String, that is a bit far fetched IMO.
>>> Conceptually, String's representing data structure is simpler - mainly
>>> just its "value", whereas Entity includes data structure that encapsulates
>>> HTTP constructs which can be rather involved. Technically, Entity has a
>>> long way to go before getting to String's status: at least it should have
>>> things like "equalIgnoreAnnotations()", "equalIgnoreLocales()", and all
>>> kinds of constructors like String has, in addition to just the static
>>> factory methods currently.
>>>
>>> Bloch talks about the non-extendable drawback of having only static
>>> factory methods. IMO this case really falls into the drawback category
>>> instead of "blessing in disguise" - i am not trying to subclass and change
>>> Entity's behavior in my source code; rather i am just trying "mock" it such
>>> that i can test i am instantiating the Entity correctly, ex. by passing in
>>> the right data as the right parameters for the multiPart contained in the
>>> Entity.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2015, 04:19 Marek Potociar <marek.potociar_at_oracle.com>
>>> wrote:
>>>
>>>> You can come up with an entity generating code. Esp. for Entity it
>>>> should be simple to implement. The arguments that you provide do not
>>>> justify your requirement to make Entity non-final. You could as well argue
>>>> for making String non-final… It just makes little sense IMO as problems
>>>> would greatly outweigh any potential benefits.
>>>>
>>>> Marek
>>>>
>>>> > On 20 Aug 2015, at 21:49, wqt.net_at_gmail.com wrote:
>>>> >
>>>> > Another clarification is that I have mixed up the terms of "stub" and
>>>> > "mock" from the get go of my question: I guess what i am wanting to do
>>>> > here is to "mock" (with check/verify/assert...) the Entity class, not
>>>> > just to "stub" it.
>>>>
>>>>
>>
> End of digest for list users_at_jax-rs-spec.java.net - Thu, 27 Aug 2015
>
>