Charles, I am not sure if the spec says which is correct. However, your assertion that the more specific match should be chosen seems correct to me. There is no benefit of the new error over the old behaviour which I can see.
Given a grey area such as this, changing the behaviour of a language in a breaking fashion (as would appear to be the case here) is definitely bad practice. We hit many such issues developing the COBOL->JVM compiler. I personally would raise this a bug based on the fact it is a breaking change to the existing Java code base. Unless the release notes on the 144 version state that this breaking change is there - then there is a bug against the code or the notes. Best wishes - AJ On 9 June 2011 14:26, Charles Oliver Nutter <head...@headius.com> wrote: > Recent OpenJDK 7 seem to have introduced a bug into javac. > Correct me if I'm wrong. > > https://gist.github.com/1016436 > > public class Foo { > public static void main(String[] args) { > method("str"); > method("str", 1); > method("str", 1, "data"); > } > > public static void method(String str, int num, Object... data) { > // do nothing > } > > public static void method(String str, Object... data) { > // do nothing > } > } > > It seems that the order in which it attempts to apply varargs and > boxing has changed. On OpenJDK/Hotspot 1.6.x and OpenJDK 7 builds > prior to 143, this compiles fine and calls the first signature for all > calls. My interpretation of the Java specification is that this is > correct behavior; the more exact signature that requires no boxing is > chosen rather than the second signature which does require boxing. > > However on later builds, we get the following errors for this case: > > Foo.java:4: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1); > ^ > Foo.java:5: error: reference to method is ambiguous, both method > method(String,int,Object...) in Foo and method > method(String,Object...) in Foo match > method("str", 1, "data"); > > Both invocations fall through to phase 3 of method selection, variable > arity. But in this case, I believe the first signature (with int) > should resolve as "more specific" than the second, and should be > chosen for both invocations. I admit it's a grey area, however, and I > can't find a specific clause in the Java spec to back me up. > > I'm not sure who to talk to about this, or whether I'm right in > thinking this is a new bug in javac. Thoughts? > > - Charlie > > -- > You received this message because you are subscribed to the Google Groups > "JVM Languages" group. > To post to this group, send email to jvm-languages@googlegroups.com. > To unsubscribe from this group, send email to > jvm-languages+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jvm-languages?hl=en. > > -- Dr Alexander J Turner http://nerds-central.blogspot.com/2008/01/about-me.html -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
