I think it is getting a bit Off-Topic, but for the licencing issue I want to mention that it was Oracle that sued Google for using Java sources in Android taken from the JDK - which is also published under an OSI-approved licence. You needed to understand that actions like these lead to sensibility at licencees. Bill is absolutely right that to 100% avoid such cases he would need to type in all your code again, which is a pain.
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.
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Montag, 13. Juni 2011 13:12
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Bill Burke
> Subject: [jsr339-experts] Re: Updated Client API and
> Interceptors/Filters proposal is available - please review
>
>
>
> On 06/09/2011 09:29 PM, Bill Burke wrote:
> > On 6/9/11 8:50 AM, Marek Potociar wrote:
> >> I don't quite understand why you push so hard for an interface in
> this particular case. Can you please provide more
> >> explanation?
> >
> > I think we all understand the benefits of an interface over a class.
> Once something is declared as a class I'm forced to
> > extend it which often leads to ugly delegation. Really, how many
> times have you been pissed off because some JDK or EE
> > thing was declared as a class and not an interface?
> >
> >
> > Besides, classes don't belong in a specification effort.
> Specifications are about specifying, not implementing unless
> > you're defining an enum or exception (and it sucks exceptions must be
> classes in Java). As it is I'm very squeamish
> > about classes over interfaces because I do have to reimplement them
> as I'm licensing with a different open source
> > license (ASL, LGPL). Given the aggressive litigation history of your
> company, maybe you can understand?
> >
>
> I don't agree that abstract or even final classes don't belong into an
> API specification effort. It always depends on
> the API and it's design.
>
> I have made the decision to make Client class abstract to avoid
> introducing a separate factory class that would serve as
> a plain wrapper for client factory methods and which would again need
> to be abstract anyway, unless you want to
> construct clients using an (abstract) RuntimeDelegate.
>
> Also, I don't understand your licensing issues. The JAX-RS 1.x defines
> abstract classes too, it has the same licensing
> approved by OSI[1] and I don't know of anyone ever having problem with
> extending any JAX-RS abstract class because of
> the licensing issues.
>
> > I made the client an abstract class to:
> >>
> >> 1. avoid the need for a separate factory class. To me, factory class
> in this case is just an artificial holder of
> >> factory methods.
> >>
> >
> > You need a factory class anyways. Either a new method on
> RuntimeDelegate or a new ClientRuntimeDelegate class.
>
> Not sure why? I have a set of factory methods dirctly in the Client
> class and those seem to be sufficient IMO.
>
> >
> >> 2. implement the instance disposal properly.
> >>
> >
> > You don't trust us to write a one line finalize method?
> >
> > Implementation details don't belong in a spec because my impl may
> want to implement something like finalize very
> > differently than how you implement it. And again, legally, I have to
> be very careful how I implement API classes.
>
> No problem, I can remove the finalizer impl if you don't like it.
>
> Marek
>
>
> [1] http://www.opensource.org/licenses/alphabetical