Thank you for doing this. The MethodHandle changes will simplify many a use case.
Cheers, — Jim > On Oct 22, 2018, at 6:58 AM, Claes Redestad <claes.redes...@oracle.com> wrote: > > Hi, > > StringConcatFactory uses a customized internal foldArguments > implementation which takes positional arguments to avoid intermediary > permutation steps, see JDK-8165492[1]. My intent has been to clean this > up for possible inclusion in the public API. > > In preparation of that, I realized that we could probably profit from a > filtering combinator on top of the existing folding one. Said and done: > > http://cr.openjdk.java.net/~redestad/8212726/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8212726 > > Using this new MethodHandles.filterArgumentsWithCombiner in place of > MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a > significant number of MethodHandles with retained performance > characteristics. In startup tests exercising indified String > concatenation the number of generated classes drops by ~25-30%, with a > measurable improvement in startup time as a result. Subjectively it also > makes the code in StringConcatFactory easier to read and follow. > > While this surely strengthens the case to include these in the public > API, I'd like to move ahead with this as an internal optimization first > and propose MethodHandles.filter-/foldArgumentsWithCombiner as public > API points as a follow-up: apart from improving the javadoc we need to > work out specification for corner cases - especially illegal values - > and harden the implementation with more tests. I'm sure there might be > opinions about the naming of these methods, too... :-) > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8165492
