users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Why is "Entity" class final

From: Qingtian Wang <wqt.net_at_gmail.com>
Date: Fri, 28 Aug 2015 09:07:22 -0500

Ok I see and understand your point of view. And I'd like to say that the
more recent specs including JAXRS from the "official" Java channels are
much more user friendly than the "j2ee" days. So thanks again for that.

Just for sake of argument, though:

1. What API leak were you referring to that can happen if the "final" key
word is removed from existing API, but all other things unchanged? I mean
you still can't subclass it...

2. I thought in OO you are supposed to leave thing open for extension, and
close to modification.... Why couldn't we provide static factory methods in
Jersey's implementation class(s) of the Entity interface?




On Fri, Aug 28, 2015 at 5:05 AM, Marek Potociar <marek.potociar_at_oracle.com>
wrote:

> I wonder how fruitful this discussion can be? The API has been released
> and we cannot change it. It provides static methods that cannot be
> facilitated in an interface. So, even if we discuss this over and over
> again, we will not be able to take any action and change Entity from a
> class to interface.
>
> Anyway, to answer the question: The motivation to make Entity a class
> rather than interface was that we can provide the static factory methods on
> it. The motivation to to make the class final was that the class completely
> encapsulates the intended functionality and we wanted to prevent unwanted
> API leaks. Restricting APIs as much as possible is considered best practice.
>
> HTH,
> Marek
>
> On 27 Aug 2015, at 11:48, Werner Keil <werner.keil_at_gmail.com> wrote:
>
> 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
>>
>>
>
>