Bug 267353

Summary: [1.5][compiler] Overloading with autoboxing handled differently from javac
Product: [Eclipse Project] JDT Reporter: dave irving <dave.irving.personal>
Component: CoreAssignee: Kent Johnson <kent_johnson>
Status: VERIFIED NOT_ECLIPSE QA Contact:
Severity: minor    
Priority: P3 CC: Olivier_Thomann
Version: 3.4   
Target Milestone: 3.5 M6   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description dave irving CLA 2009-03-06 08:16:04 EST
The following code snippet demonstrates the problem:


public class Example {

  public void doSomethingWith(Object target) {
  }

  private void doSomethingWith(int target) {
  }
}

public class Tester {

  public void testIt() {
    int value = 123;
    Example example = new Example();
    example.doSomethingWith("hello");
    example.doSomethingWith(value); // causes compile error under javac
  }

}

'Tester' compiles fine in Eclipse 3.4.
However, it does not compile against javac (1.5 or 1.6).

I suspect (although Im no expert) that this has something to do with the multi-step method signature determination (http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#292575).

My _guess_ is that in step one, javac finds an _applicable_ method - but this isn't accessible - so doesn't go further (giving the back-compatibility with pre java 5, where this obviously shouldn't compile due to lack of autoboxing).
So, under javac, we get the compilation error: "doSomethingWith(int) has private access in Tester".

Is perhaps JDT allowing the autoboxing conversion (http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#12687) here when it shouldn't?
Comment 1 dave irving CLA 2009-03-06 08:44:48 EST
Hmmm. 

Looking closer at 15.12.2 of the JLS - the first step involves finding _all_ potentially applicable methods. The subsequent steps appear to attempt to find one or more applicable methods from the initial set of potentially applicable methods.

Given that, surely doSomethingWith(int) cant be a potentially applicable method - and thus I'd expect an applicable method to be found in phase 2 (15.12.2.3) - applying boxing to select doSomethingWith(Object) as the applicable method.

So I'm beginning to think that perhaps its actually Eclipse which is doing the right thing here..... 
All I can confirm, of course, is that Eclipse and javac are not agreeing :)
Comment 2 Kent Johnson CLA 2009-03-09 16:02:54 EDT
The example compiles successfully with javac 7

Whatever issue javac had, has been fixed.
Comment 3 Frederic Fusier CLA 2009-03-10 10:14:40 EDT
Verified for 3.5M6