Fwd: [jvm-l] Newly introduced OpenJDK javac bug?

[Rémi Forax]

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 <headius at headius.com>
Reply-To: 	jvm-languages at googlegroups.com
To: 	JVM Languages <jvm-languages at googlegroups.com>
CC: 	Mark Reinhold <mark.reinhold at oracle.com>



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 jvm-languages at googlegroups.com.
To unsubscribe from this group, send email to jvm-languages+unsubscribe at googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20110609/ced34cb4/attachment.html