Updating to Java 8 would be fine with me. You could write a [poll] email
thread the ML to gauge interest.
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
