> >>> On 06/13/2011 02:46 PM, Markus KARG wrote:
> >>>> For the topic of factories itself I share Bill's opinion that
> >> whenever possible we should use interfaces and do not provide
> >> implementations. As much as possible of the implementation should be
> in
> >> the sole hands of the vendors and not already pre-programmed by the
> >> spec. If using a ClientFactory is the solution, then we should
> provide
> >> one. It's just the cleaner approach.
> >>>
> >>> Can you please provide an example of constructing a client instance
> >> with the client factory you propose? Does your
> >>> client factory have static methods? If yes, it must be at least an
> >> abstract class then, which means we are just moving
> >>> the problem one level of indirection further.
> >>
> >> Exactly. It doesn't matter how many factory classes we create, we'll
> >> need an abstract class for the static methods at some point. Earlier
> >> feedback on the API was related to the number of classes; adding an
> >> extra level of indirection seems to go against that and without any
> >> clear benefits IMO.
> >>
> >
> > The clear benefit would be that if we move the problem to a single
> point
> > then everything beyond that point can be decided by the implementor.
>
> This is a valid point. The problem that I see is that in the absence
> of DI, you'd need to write something like this if you were to use
> RuntimeDelegate:
>
> Client c =
> RuntimeDelegate.getInstance().buildClientFactory().createClient();
>
> At least if we follow the current model in which RuntimeDelegate does
> not have static methods. This seems a bit much to create an instance of
> Client.
This is correct, but it is valid to do so. See, other Java EE APIs also have
such complex initializations. When using JPA for example, one has to do:
Persistence.createEntityManagerFactory().createEntityManager(). Persistence
uses PersistenceProvider to delegate the factory creation to a third party
implementation. So we could reduce to that level of complexity by doing
something like this: Rest.createClientFactory().createClient() and let Rest
use RuntimeDelegate to build the factory. If people accept this in JPA, why
shouldn't they in JAX-RS?
> > In the end, you're having set up the EG to get those experts'
> opinions, so I
> > don't see what you problem now is with that opinions? Was there a
> poll among
> > the experts that ended with "We MUST merge ClientFactory into Client
> to
> > preserve on class?" and Bill and me just missed that?
>
> Hmmm. I don't understand your point here. I was expressing my opinion,
> just like you. No poll/decision has been made on this, we are all just
> trying to figure out the best way to do this.
Interpreting the posts of Oracle members in the past days (at least to me)
it sounded more like convincing the EG of the existing proposal than finding
an implementation for what the EG proposed. If this was not Oracle's
intention then everything is OK, at least for me, and I think for Bill also.
Regards
Markus