commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Klein <coryfkl...@gmail.com>
Subject Re: [POOL] Improving the borrow/return process with anonymous functions
Date Thu, 12 Nov 2015 19:03:10 GMT
> 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 <garydgregory@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" <coryfklein@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message