On Thu, Nov 12, 2015 at 12:25 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
> Updating to Java 8 would be fine with me. You could write a [poll] email
> thread the ML to gauge interest.
>
First, thanks for your interest in contributing, Cory!
I am not sure this idea belongs in GOP itself. A GOP is not an application
container - just an object reference pool. The contract is simple -
callers borrow objects, use them and return them. This has proven a very
useful contract that gives us pretty clean separation of concerns and
limited resource management responsibility. In earlier versions, we did
not even hold references to objects in circulation. It is hard enough as
it is for us to maintain good performance and stability just managing
references. It's interesting that you see this as reducing leakiness - I
actually see it the other way; but I do get your point on convenience. To
be fair, I recently proposed adding generic proxy capability in a
specialized pool, but later agreed it was out of scope for [pool].
A compromise that I would not object to would be to create a different pool
type, accessible via PoolUtils, that adds this functionality. Even then, I
am not sure I would relish the task of debugging problems when
user-supplied functions did funny things. I am interested to hear what
others think about this idea.
Thanks again for digging into the code and thanks in advance for your
contributions.
Phil
>
> Gary
>
> On Thu, Nov 12, 2015 at 11:03 AM, Cory Klein <coryfkl...@gmail.com> wrote:
>
> > > The first hurdle here is that pool is not on Java 8. But this could be
> > done
> > > with other facilities like Runnable, Callable, maybe even an executor.
> >
> > Although Callable wouldn't be as elegant as lambdas, it would
> > definitely be possible. The consumer could define a Callable:
> >
> > class ResourceCallable implements Callable<String> {
> > private MyResource resource;
> > public ResourceCallable(MyResource resource) {
> > this.resource = resource;
> > }
> >
> > public String call() {
> > return doSomething();
> > }
> >
> > public String doSomething() {
> > ...
> > }
> > }
> >
> > Then it passes that callable's type into run with its return type:
> >
> > String result = objectPool.run(ResourceCallable.class, String.class)
> >
> > Then maybe something like this for the definition of run:
> >
> > public class <T> ObjectPool {
> > ...
> > public <U> U run(Class<S> callableType, Class<U> returnType) {
> > // Leaving out exception handling for brevity
> > T obj = borrowObject();
> > S callable = callableType.getConstructor().newInstance(obj);
> > U result = callable.call();
> > returnObject(obj);
> > return result;
> > }
> > }
> >
> > So yea, not quite as pretty as with lambdas. Is it expensive to
> > upgrade the Java version of a commons lib like pool? Java 8 will be 2
> > years old in March, but I'm sure there would be plenty of people
> > unable to consume a version that jumps from 1.6 to 1.8.
> >
> > Looks like the last time we upgraded was from 1.5->1.6 in Feb 2012
> > because "1.5 is out of support unless you pay for it" (git sha
> > d44c8f6).
> >
> > On Thu, Nov 12, 2015 at 10:55 AM, Gary Gregory <garydgreg...@gmail.com>
> > wrote:
> > > The first hurdle here is that pool is not on Java 8. But this could be
> > done
> > > with other facilities like Runnable, Callable, maybe even an executor.
> > >
> > > Gary
> > > On Nov 12, 2015 9:47 AM, "Cory Klein" <coryfkl...@gmail.com> wrote:
> > >
> > >> First off, hello! My name is Cory Klein and this marks my first
> > >> interaction with this group. I've read through the email guidelines
> > >> and I think I have something productive to discuss here.
> > >>
> > >> In looking at GenericObjectPool I came across a process that I believe
> > >> could be improved upon and I wanted to get some early feedback on this
> > >> approach before investing the time to create a full pull request.
> > >>
> > >> The general approach for using an object pool is to borrow an object,
> > >> use it to do something, and then return it. For example:
> > >>
> > >> Resource resource = objectPool.borrowObject();
> > >> String result = doSomething(resource);
> > >> objectPool.returnObject(resource);
> > >>
> > >> In this case, objectPool owns instances of Resource and lends them
> > >> out. However, the object pool abstraction gets slightly leaky when you
> > >> consider that the consumer has a responsibility to return the object,
> > >> and other consumers might be adversely affected if objects aren't
> > >> returned properly.
> > >>
> > >> I propose augmenting ObjectPool with the following method. This code
> > >> is merely demonstrative and not intended to be final:
> > >>
> > >> public class <T> ObjectPool {
> > >> ...
> > >>
> > >> public R run(Function<T,R> function) {
> > >> T obj = null;
> > >> try {
> > >> obj = borrowObject();
> > >> } catch (Exception e) {
> > >> throw new RuntimeException("Unable to get object from
> > pool");
> > >> }
> > >> R returnVal = null;
> > >> try {
> > >> returnVal = function(T);
> > >> } catch (Exception e) {
> > >> throw new RuntimeException("Supplied lambda produced an
> > >> exception");
> > >> } finally {
> > >> this.returnObject(obj);
> > >> return returnVal;
> > >> }
> > >> }
> > >> }
> > >>
> > >> With this idea, consumers can instead provide the object pool with a
> > >> function to run using the required resource, leaving the object pool
> > >> complete ownership of the resource and ensuring that resources can
> > >> always be returned to the pool. The borrow/return example from above
> > >> becomes merely:
> > >>
> > >> String result = objectPool.run((resource) -> doSomething(resource));
> > >>
> > >> In summary, some positive reasons I can think of to make this change
> > are:
> > >>
> > >> * Improve a leaky abstraction
> > >> * Less code needed on the consuming side
> > >> * Improved reliability
> > >>
> > >> I'm having a harder time coming up with reasons why this change is
> > >> bad, but I think this may be due to a lack of intimacy with the
> > >> library as it exists now. Are there any reasons that are immediately
> > >> apparent to you?
> > >>
> > >> Thanks,
> > >>
> > >> Cory Klein
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > >> For additional commands, e-mail: dev-h...@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
