Community
Participate
Working Groups
While playing with null-annotation support (bug 186342) I found the following non-sense code: DefaultBindingResolver:1530 reads: return getTypeBinding(this.scope.createArrayType(binding, arrayType.getDimensions())); At this point the analysis knows that 'binding' is definitely null. Inside createArrayType(..) the first action is to dereference that parameter. If that could would ever get executed it would definitely throw NPE. This manifested in a conflict that the parameter in question could neither be type-checked with @Nullable nor with @NonNull.
In fact that code can never be run. I'll clean it up.
Created attachment 189706 [details] Proposed fix
(In reply to comment #1) > In fact that code can never be run. I had hoped so :) So the code was trying to protect against inconsistencies between the dom Type and the compiler TypeBinding (one being an array type while the other's not)? And by now we're confident that such inconsistency will never occur? Sounds good to me.
(In reply to comment #3) > So the code was trying to protect against inconsistencies between the dom Type > and the compiler TypeBinding (one being an array type while the other's not)? > > And by now we're confident that such inconsistency will never occur? > Sounds good to me. I believe the code was over paranoiac. At that point, it can only be an array type with an array type binding. So I'll run all tests for safety and I'll release afterwards.
Released for 3.7M6.
(In reply to comment #4) > I believe the code was over paranoiac. At that point, it can only be an array > type with an array type binding. I filed bug 339226 for recovering the underlying tacit knowledge.
Verified for 3.7M6 via code inspection.