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

From: Qingtian Wang <>
Date: Fri, 21 Aug 2015 16:18:33 +0000

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);
// 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 <> 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 <>
> 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, 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.