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