[
https://issues.apache.org/jira/browse/TAP5-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Weidig reassigned TAP5-2746:
--------------------------------
Assignee: Ben Weidig
> tapestry-func should move to JDK functional classes
> ---------------------------------------------------
>
> Key: TAP5-2746
> URL: https://issues.apache.org/jira/browse/TAP5-2746
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-func
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Minor
>
> Due to historical reasons, tapestry-func duplicates a lot of functionality
> that is now provided by the JDK itself.
> For example:
> * org.apache.tapestry5.func.LazyValue<T> is a java.util.function.Supplier<T>
> * org.apache.tapestry5.func.Worker<T> is a java.util.function.Consumer<T>
> * org.apache.tapestry5.func.Predicate<T> is a java.util.function.Predicate<T>
> I propose the following changes:
> * The existing types should extend their JDK equivalent, with the
> single-abstract method of the JDK variant calling the original one.
> This way, no existing code will break, but all the convenience methods from
> the JDK type are available.
> * tapestry-func types should be marked as deprecated
> * Types using the tapestry-func types should accept the JDK variants instead
> * Mark the types as @FunctionalInterface
>
> However, replacing org.apache.tapestry5.func.Flow<T> with
> java.util.stream.Stream<T> seems like overkill to me.
> It would need to be benchmark, but my educated guess is that the overhead of
> Streams wouldn't justify a replacement.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
