You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently ParseCallback extends java.util.function.BiFunction. That requires it to use the boxed type Integer as parameter instead of the primitive type int. This might cause some performance overhead due to boxing and unboxing (I haven't measured it though).
Suggested solution
Don't let ParseCallback extend java.util.function.BiFunction. Even without extending BiFunction users can use a lambda expression or method reference for this interface. And you can then freely choose parameter and return types.
I am not sure if extending BiFunction provides much or any advantages. For example the default methods such as BiFunction#andThen return a BiFunction, so they cannot be used for anything which expects a ParseCallback.
What do you think?
(This also applies to Logger which extends BiConsumer.)
The text was updated successfully, but these errors were encountered:
Problem
Currently
ParseCallback
extendsjava.util.function.BiFunction
. That requires it to use the boxed typeInteger
as parameter instead of the primitive typeint
. This might cause some performance overhead due to boxing and unboxing (I haven't measured it though).Suggested solution
Don't let
ParseCallback
extendjava.util.function.BiFunction
. Even without extendingBiFunction
users can use a lambda expression or method reference for this interface. And you can then freely choose parameter and return types.I am not sure if extending
BiFunction
provides much or any advantages. For example the default methods such asBiFunction#andThen
return aBiFunction
, so they cannot be used for anything which expects aParseCallback
.What do you think?
(This also applies to
Logger
which extendsBiConsumer
.)The text was updated successfully, but these errors were encountered: