Hi, <snip> How can the compiler know whether max(1,2,3) is max(a,b,c) or max(a...) ? </snip>
max(1,2,3) is compiled to max(a,b,c). The compiler will use the finer method instead of using the more generic one. This is used for example in logging frameworks: there are multiple methods: log(String message) log(String message, Object arg) log(String message, Object arg1, Object arg2) log(String message, Object...args) This is used as an optimization to avoid the cost of creating an array for each var args call. My 2 cents, Julien 2014-05-06 2:21 GMT+04:00 sebb <seb...@gmail.com>: > On 5 May 2014 22:14, Benedikt Ritter <benerit...@gmail.com> wrote: >> >> >>> Am 05.05.2014 um 22:20 schrieb sebb <seb...@gmail.com>: >>> >>>> On 5 May 2014 18:40, Benedikt Ritter <brit...@apache.org> wrote: >>>> Hi, >>>> >>>> we have a pull request at github for [lang] which proposes to introduce new >>>> methods in NumberUtils that take varargs as input parameters instead of >>>> arrays [1]. I think a better solution would be to change those old methods >>>> to use varargs instead of introducing new methods. Since I'm not sure how >>>> this affects binary compatibility, I'd like to here what others thing about >>>> this. >>>> >>>> Clirr doesn't even create an info for a change like this, so I'm assuming >>>> it can be changed without affecting clients. >>> >>> In most cases, the effect is the same, but there are some edge cases >>> according to >>> >>> http://stackoverflow.com/questions/5405673/java-varags-method-param-list-vs-array >>> >>> However, I don't like the proposed solution which needs new names. >> >> Yes, I don't like that either. >> >>> One way round this might be to extend the existing methods as follows: >>> >>> max(a,b,c,...) >> >> This would be a solution. But why not change max(a[]) to max(a...) if it is >> binary compartible? > > How can the compiler know whether max(1,2,3) is max(a,b,c) or max(a...) ? > >> The corner case mentioned in the stackoverflow article seems to be about >> generic varargs parameters. > > Yes, it does seem to only affect code that would not have compiled previously. > >>> >>> I think this was already done in some Commons code? >> >> I've had a brief look at StringUtils. There were some changes like this >> documented by they happend to be implemented in 3.0, so I was unsure :-) >> >>> >>>> Benedikt >>>> >>>> >>>> [1] https://github.com/apache/commons-lang/pull/23 >>>> >>>> -- >>>> http://people.apache.org/~britter/ >>>> http://www.systemoutprintln.de/ >>>> http://twitter.com/BenediktRitter >>>> http://github.com/britter >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
