+1 to what Peter said: it's a functional interface so it is
lambda-compatible anyway.
Matt
On Apr 12, 2015 6:49 PM, "Peter Ansell" <ansell.pe...@gmail.com> wrote:
> On 12 April 2015 at 21:14, Benedikt Ritter <benerit...@gmail.com> wrote:
> > Hi,
> >
> > there is currently a discussion on github about the addition of a low
> level utility class which helps to retrieve Threads [1]. The latest
> proposal is to implement a predicate based approach for filtering threads
> [2]. My opinion is, that we should not add such an API at all, because we
> would have to revert it anyway, when we upgrade [lang] to Java 8. Further
> more I don't think it is a good idea to add a generic Pedicate interface to
> [lang]. This will only cause confusion for users already using Java 8. So
> if we really want to add predicate based API in ThreadUtils, it should IMHO
> Look like this:
> >
> > Collection<Thread> ThreadUtils.findThreads(ThreadPredicate filter)
> >
> > public interface ThreadPredicate {
> > boolean test(Thread);
> > }
>
> In my Java-8-only code, the above is what I already do. The only
> addition once you get to Java-8 as a baseline would be to add
> @FunctionalInterface as a class annotation, to enable the compiler to
> verify that it stays as a functional interface.
>
> > Later we can change this to:
> >
> > Collection<Thread>
> ThreadUtils.findThreads(java.util.function.Predicate<Thread> filter)
>
> It is completely unnnecessary to make the change above, although with
> the change below it should not disturb any code that was already using
> it due to the way lambda matching works.
>
> > public interface ThreadPredicate extends
> java.util.function.Predicate<Thread>
>
> This change is useful once JDK-8 is the baseline, as it would only add
> features (all of the default methods) from Predicate, not remove any
> features or backwards compatibility.
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
