On Jun 9, 2011, at 6:31 PM, Alexander Turner wrote: > 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.
I won't pretend to understand all of the arguments that Neal and Remi are making and I trust that they are correct in their assessments. However, leaving things in a "broken state" is not without precedence. My earliest experience was with Cray's "broken" floating operation. Cray offered to move to a IEEE floating point implementation that would "fix" the problem but in the end the users came back with a resounding, we've accounted for the bug and this will break stuff that we don't want to or can't afford to revisit and so we don't "the fix" even though we recognize it to be correct. In my personal experience I've fixed incongruent behavior in a C lib that caused no end of (unexpected) grief. The "fix" was immediately rolled back. In both cases, the community of affected users was small. That certainly isn't the case with Java. Regards, Kirk > 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. > -- 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.
