> 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