We have a class LogManager in our Java project which looks like this:
public class LogManager {
public void log(Level logLevel, Object... args) {
// do something
}
public void log(Level logLevel, int value, Object... args) {
// do something else
}
}
When compiling the project with OpenJDK 6 under Debian everyting
works fine. When using OpenJDK 7 the build (done with ant)
produces the following errors and the build fails:
[javac] /…/LogManager.java:123: error: reference to log is ambiguous,
both method log(Level,Object...) in LogManager
and method log(Level,int,Object...) in LogManager match
[javac] log(logLevel, 1, logMessage);
[javac] ^
[javac] /…/SomeOtherClass.java:123: error: reference to log is ambiguous,
both method log(Level,Object...) in LogManager
and method log(Level,int,Object...) in LogManager match
[javac] logger.log(logLevel, 1, logMessage);
[javac] ^
As long as the 1 is not autoboxed, the method call should be
unambiguous as 1 is an int and cannot be upcast to Object. So why
doesn’t autoboxing overrule varargs here?
Eclipse (installed using the tar.gz from eclipse.org) compiles it no
matter if OpenJDK 6 is installed or not.
Thank’s a lot for your help!
Edit:
The compiler gets the option source="1.6" and target="1.6" in both cases. The Eclipse compiling note is just meant as a comment.
I guess it’s related to bug #6886431, which seems to be fixed in OpenJDK 7 as well.
The problem is that JLS 15.12.2.5 Choosing the Most Specific Method
says that one method is more specific than another one when types of formal parameters of the former are subtypes of formal parameters of the latter.
Since
intis not a subtype ofObject, neither of your methods is the most specific, thus your invocation is ambiguous.However, the following workaround is possible, because
Integeris a subtype ofObject: