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 <mailto: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 <mailto:marek.potociar_at_oracle.com>>
> 2. [jax-rs-spec users] Re: Why is "Entity" class final - Qingtian Wang <wqt.net_at_gmail.com <mailto:wqt.net_at_gmail.com>>
>
>
>
> ---------- Forwarded message ----------
> From: Marek Potociar <marek.potociar_at_oracle.com <mailto:marek.potociar_at_oracle.com>>
> To: users_at_jax-rs-spec.java.net <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:wqt.net_at_gmail.com>>
> To: users_at_jax-rs-spec.java.net <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:users_at_jax-rs-spec.java.net> - Thu, 27 Aug 2015
>
>