Community
Participate
Working Groups
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?
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 :)
The example compiles successfully with javac 7 Whatever issue javac had, has been fixed.
Verified for 3.5M6
