P3
Here is the chain of emails exchanged on the QueryFactory class:
------------------------------------------------------------------
Jonathan,
my ansers inline...
Jonathan Bruce wrote:
>
>
> Amit Handa wrote:
>
>> Hi Jonathan,
>>
>> A few things about QueryFactory class
>>
>> 1. It has only one static method, so am wondering what will we use the constructor for ?
>> I suggest we don't require that.
>
>
>
> It should never be constructed... it is merely a helper class to get the annotation and query process kicked off.
>
Surprisingly the constructor is there in Javadocs and *not*
in your spec class, We don't need this to come in Javadocs
and I think we are on the same page on this.
Can you please do something to suppress the constructor coming in Javadoc ?
>>
>> 2. And, can we have this as a abstarct class ?
>
>
>
> Why ? It should never be implemented other than by Sun.
I do not agree here, please correct me below.
Being a spec class, it should be available to *all* to use,
We can't define something(class or interface) in spec which only Sun can use and nobody else ?
> People can just extend this class, as it is not final.
>
>> So that driver vendors can subclass it and plugin their own implementations,
That is why I am saying it should be abstract.
Also giving vendors *flexibility* to provide their own implementations.
Other thing is if we do *not* make it abstract the class
in itself should be able to behave
>> since it can be implemented in many ways.
>> else we will force vendors to use our implementation which may not be a flexible idea.
>>
>> 3. From our perspective(RI) also we need QueryFactory to implement InvocationHandler
>> interface so that it can generate implementations of classes on the fly(i.e at runtime),
>> which is not possible if we keep it as a class and not an abstract one.
>> If we are able to extend such a class we have that flexibility.
>> At the same time we cannot force a spec class(QueryFactory class) to implement InvocationHandler
>
>
Yes, I am sure,
For one I will e mail the alias and confirm too.
What I am saying is that the QueryFactory class anyway has to get extended
to be used, it cannot be used *as such*. So why not have it abstract ?
Though the present way i.e keeping it as a class won't harm but
what I am suggesting would be a better design.
>
> Are you sure this is a specific limitation - I can't find anything in docs that indicates this. Can you contact Mark Roth or ###@###.### and get a specific fix on whether we have to move to a more abstract definition. Also note, if we have an abstract class, we will have to provide our own standard implementation, and an additional framework so people can understand how to over-ride this...
>
> -Jonathan
>
>
>>
>> Kindly look at these inputs and we can always discuss this in next engg.
>> as and when it happens.
>>
>> thanks,
>> Amit
------------------------------------------------------------------
Jonathan,
my ansers inline...
Jonathan Bruce wrote:
>
>
> Amit Handa wrote:
>
>> Hi Jonathan,
>>
>> A few things about QueryFactory class
>>
>> 1. It has only one static method, so am wondering what will we use the constructor for ?
>> I suggest we don't require that.
>
>
>
> It should never be constructed... it is merely a helper class to get the annotation and query process kicked off.
>
Surprisingly the constructor is there in Javadocs and *not*
in your spec class, We don't need this to come in Javadocs
and I think we are on the same page on this.
Can you please do something to suppress the constructor coming in Javadoc ?
>>
>> 2. And, can we have this as a abstarct class ?
>
>
>
> Why ? It should never be implemented other than by Sun.
I do not agree here, please correct me below.
Being a spec class, it should be available to *all* to use,
We can't define something(class or interface) in spec which only Sun can use and nobody else ?
> People can just extend this class, as it is not final.
>
>> So that driver vendors can subclass it and plugin their own implementations,
That is why I am saying it should be abstract.
Also giving vendors *flexibility* to provide their own implementations.
Other thing is if we do *not* make it abstract the class
in itself should be able to behave
>> since it can be implemented in many ways.
>> else we will force vendors to use our implementation which may not be a flexible idea.
>>
>> 3. From our perspective(RI) also we need QueryFactory to implement InvocationHandler
>> interface so that it can generate implementations of classes on the fly(i.e at runtime),
>> which is not possible if we keep it as a class and not an abstract one.
>> If we are able to extend such a class we have that flexibility.
>> At the same time we cannot force a spec class(QueryFactory class) to implement InvocationHandler
>
>
Yes, I am sure,
For one I will e mail the alias and confirm too.
What I am saying is that the QueryFactory class anyway has to get extended
to be used, it cannot be used *as such*. So why not have it abstract ?
Though the present way i.e keeping it as a class won't harm but
what I am suggesting would be a better design.
>
> Are you sure this is a specific limitation - I can't find anything in docs that indicates this. Can you contact Mark Roth or ###@###.### and get a specific fix on whether we have to move to a more abstract definition. Also note, if we have an abstract class, we will have to provide our own standard implementation, and an additional framework so people can understand how to over-ride this...
>
> -Jonathan
>
>
>>
>> Kindly look at these inputs and we can always discuss this in next engg.
>> as and when it happens.
>>
>> thanks,
>> Amit