add compiler dev-list to the loop. My analysis is that this is a fix for a previously existing bug, so the behavior of javac is now correct.
With method("str", 1), no method are applicable without considering boxing and varargs,
so we ends up with phase 3. Here, both boxing and varargs are enabled so the two method are applicable and not one is most specific. So the call is ambiguous. Rémi -------- Original Message -------- Subject: [jvm-l] Newly introduced OpenJDK javac bug? Date: Thu, 9 Jun 2011 08:26:04 -0500 From: Charles Oliver Nutter <[email protected]> Reply-To: [email protected] To: JVM Languages <[email protected]> CC: Mark Reinhold <[email protected]> Recent OpenJDK 7 builds 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
