Hi, Alternatively you could create the variants whose parameters can be passed utilizing "all available registers", whatever that means in Java context. The rationale is that the reason for preferring variables over varargs is performance and this way there is no performance left on the table.
Sent from Mail for Windows 10 From: Paul Sandoz Sent: Wednesday, October 14, 2015 11:38 Cc: core-libs-dev Subject: Re: RFC: draft API for JEP 269 Convenience Collection Factories > On 14 Oct 2015, at 06:18, Stuart Marks <stuart.ma...@oracle.com> wrote: > I'm not entirely sure what to take from this. If it were clearly exponential, > we could say with confidence that above a certain threshold there would be > vanishingly little benefit adding more arguments. But since the curve seems > to flatten out, maybe this is pushing us to add more pairs than we had > originally thought. The current draft API has 8 pairs; that seems to leave a > few percent of cases on the table. Obviously we can't get to 100%, but is 97% > good enough? > 11 if only for amusement purposes :-) Capturing 9 out of 10 cases seems reasonable to me i.e. 5 entries. Perhaps a common case for r > 5 entries is a map for the primitive types and ref (ignoring “void”), which would push the limit up to 9 entries. I took a quick browse through the JDK and it is not that common AFAICT. j.l.invoke tends to use enums for example. There are two cases in java.ObjectInputStream and sun.misc.ProxyGenerator. Paul.
