Hi Phil,
>>
>> org.apache.commons.pool2.impl
>> |---- generic
>> |---- reference
>> |---- stack
>>
>> common stuff could be included directly under impl.
>>
>
> What exactly would that be?
>
just realized that there are no common stuff shared by different kind of pool :P
>
> I was going to propose dropping the stack pools altogether. The LIFO/FIFO
> config option in the generic pools makes them mostly irrelevant (i.e., you
> can get the same behavior with a suitably configured GOP / GKOP with much
> more configurability)
>
I had the same feelings here, but felt a little shy on saying that.
You've my full support on this, I agree on dropping stack based pool
implementations.
> I don't want to sound too conservative and I will certainly not stand in the
> way of new / different pool implementations, but I would personally prefer
> to keep the number of included pool impls as small as possible.
>
I propose a more democratic way, I mean, like you made us notice,
keeping/adding the pool impl only if it makes sense to.
I wouldn't think about the included pools in therms of "size" but
rather in therms of "meaning"
> I think the first thing we need to do is to decide what implementations we
> are going to a) keep or b) add for 2.0. I have been convinced that we need
> to keep GKOP as well as GOP. As I said above, I would like to consider
> dropping the stack-based pools. I think we should keep the reference-based
> pool and I am open to the new ones you suggest, just don't have use cases
> myself for them.
I'm not ready to show use cases too, sorry :( But they can be added
with a trivial refactory, moving the current SoftReferenceObjectPool
implementation to an
AbstractReferenceObjectPool<T, R extends Reference<T>> extends
BaseObjectPool<T> implements ObjectPool<T>
then in subclasses do the minimum. I can quickly provide a patch for it.
> There are quite a few impls buried in PoolUtils that might
> make sense to pull out (or eliminate).
>
I just made a census (with proposals):
* PoolableObjectFactoryAdaptor
* KeyedPoolableObjectFactoryAdaptor
* ObjectPoolAdaptor
* KeyedObjectPoolAdaptor
I propose to eliminate these adaptors, they implement a behavior that
users can replicate with a trivial code and without build a
pool/factory on top of an existing ones
* CheckedObjectPool
* CheckedKeyedObjectPool
These can be eliminated too, having introduced the generics
* ObjectPoolMinIdleTimerTask
* KeyedObjectPoolMinIdleTimerTask
I propose these pools can be pulled out and moved to a proper package
* SynchronizedObjectPool
* SynchronizedKeyedObjectPool
* SynchronizedPoolableObjectFactory
* SynchronizedKeyedPoolableObjectFactory
These could be pulled out too, even if something suggests me that
pools synchronization can be realized with just a Proxy, I'll do a
little experiment to submit so you can evaluate.
> What might make sense is to replace "impl" with "instance" (or "object") and
> "reference" (or "ref"). So you have o.a.c.p, o.a.c.p.instance,
> o.a.c.p.reference.
>
sounds much better than keeping the intermediate "impl", I agree :)
Should I have to write all these notes on the wiki and open issues
before proceeding?
Many thanks in advance, have a nice day!
Simo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
