Community
Participate
Working Groups
Build: I20060815 There are several pieces of code in OSGi that have a pattern like the one below. These appear as potential null reference warnings, but from flow analysis you can see that it is impossible for the reference to be null: public void doit(Object[] array) { int length = array == null ? 0 : array.length; if (length == 0) return; System.out.println(array[0]);//null reference warning }
This adds some complexity to bug 125319: - the considered length and array are not final; - the protection involves a different control flow (deep return instead of embedded block).
Reopening as P5 (since RESOLVED LATER is deprecated).
Ayush & Stephan, Where has the resolution of bug 247564 left us with vis-à-vis the current one ?
(In reply to comment #3) > Ayush & Stephan, > > Where has the resolution of bug 247564 left us with vis-à-vis > the current one ? Bug 247564 has not introduced any correlation analysis. Nor do I have plans to implement such analysis, because I believe the complexity of such analysis would be way beyond all that we have today. I expect the costs both in development time and probably also performance / memory consumption to outweigh the benefit. That said, the reference to bug 125319 is new for me and I'm curious to investigate if any of the work that has been started there looks promising. Yet, _this_ bug "adds some complexity to bug 125319" so I don't want to grow any expectations here. Looking at the NullPatternsHandler from bug 125319 any solution in that direction will certainly be limited to a narrow range of code patterns (it may avoid the pot. performance issues, though). OTOH, I see no reason why the null analysis should jump through hoops to accommodate this code which so easily could be rephrased, e.g., as public void doit(Object[] array) { if (array == null || array.length == 0) return; System.out.println(array[0]); // known to be safe } this version can be easily understood by both human *and* compiler. It is actually a message from bug 247564 that certain guarantees can only be given if the code is rephrased into a safer variant, e.g.: class X { Object o; @NonNull Object foo() { if (o != null) { possiblySomeStuffHere... return o; // (1) } Object local = o; if (local != null) { possiblySomeStuffHere... return local; // (2) } } } (1) violates the null specification (due to concurrency or field updates in methods called from possiblySomeStuffHere) (2) is a fully safe alternative, understood by the analysis Saying: wrt fields our analysis should actually direct the user to reduce the number of direct field accesses and use more local variables inside a method. A similar message regarding correlation might be: "don't rely on correlation, protect array access by a direct check for null, not by a check on a derived value." As an aside, in bug 335118 I had started to refactor the JDT/Core code in the same vein as illustrated above. Maybe by continuing that work we will get a better idea about the practicality of such refactoring.
Bulk closing all compiler bugs tagged [null][correlation], because we have no plans to add such a feature: it would be a tremendous implementation effort, beyond our current man power, and may be impossible to achieve within the desired performance bounds. If s.o. has a viable strategy or even implementation for such a feature, I'm all ears.
Verified for 4.7 M1
I created a new umbrella RFE outlining what would be needed to address this issue. *** This bug has been marked as a duplicate of bug 538421 ***
