This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Consider the following example (separate source files for A and B): public class A { public void foo(int n) { } private void foo(Integer n) { } } public class B { public void test(A a, Integer n) { if (n != null) { a.foo(n.intValue()); } } } NetBeans shows a warning hint "Unnecessary unboxing" on the intValue() call. However, when removing the intValue() call, the code doesn't compile anymore ("foo(java.lang.Integer) has private access in A"). It seems that when evaluating whether the unboxing is "unnecessary", NetBeans needs to take possible private overloads into account.
It seems this is only an issue under JDK 6.
(In reply to matthies from comment #1) > It seems this is only an issue under JDK 6. Do you mean that you run NB under JDK6, or your project is set up with JDK6 platform, or do you compile for JDK6 (source/binary format setting) ?
(In reply to Svata Dedic from comment #2) > (In reply to matthies from comment #1) > > It seems this is only an issue under JDK 6. > > Do you mean that you run NB under JDK6, or your project is set up with JDK6 > platform, or do you compile for JDK6 (source/binary format setting) ? Not sure what I had been observing. I now get the warning hint for all of 6/7/8 JDK and/or source/binary format, with NetBeans 8.0.2 running on JDK 8.
(In reply to matthies from comment #3) > Not sure what I had been observing. I now get the warning hint for all of > 6/7/8 JDK and/or source/binary format, with NetBeans 8.0.2 running on JDK 8. the warning should be OK (at least I think) -- the compiler should be able to resolve the correct overload with respect to method visibility. I've tried JDK7 and JDK8 compilers, and they both compile the code with removed .intValue() unboxing fine without errors - the comment #1 looked like JDK6 compiler has an issue with the simplified code.
Hi, reopening because the example code doesn't compile with the JDK 1.6 platform after applying the hint. Hence you might reconsider whether to fix this or not. In comment #3 I had missed that this bug isn't about the warning itself, but about the non-compiling code resulting from applying the hint.
(In reply to matthies from comment #5) > Hi, reopening because the example code doesn't compile with the JDK 1.6 > platform after applying the hint. Hence you might reconsider whether to fix > this or not. In comment #3 I had missed that this bug isn't about the > warning itself, but about the non-compiling code resulting from applying the > hint. ah, OK. I confirm that javac shipped with JDK6 fails on the "corrected" source. JDK7 works OK. As reporting the error is most probably violating the JLS, I cowardly close the defect as WONTFIX bcs. of JDK bug. I cannot reliably avoid the situation in the hint infrastructure for JDK6 target: I am using javac parts to resolve the method call, and NB contains javac with that defect already fixed. Duplicating the method resolution algorithm would be terrible / error prone. Sorry.