You can have 255 parameters for a method, it's perhaps a little too much, isn't it ?
cheers, Rémi Le 14 octobre 2015 12:40:15 CEST, Timo Kinnunen <timo.kinnu...@gmail.com> a écrit : >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.
