> 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
