Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 355449

Summary: [assist] NPE when proposing to materialized inferred callout
Product: [Tools] Objectteams Reporter: Stephan Herrmann <stephan.herrmann>
Component: OTDTAssignee: Stephan Herrmann <stephan.herrmann>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: P3    
Version: 2.0   
Target Milestone: 2.1 M4   
Hardware: Other   
OS: Linux   
Whiteboard:

Description Stephan Herrmann CLA 2011-08-22 19:10:09 EDT 
Maybe the following stack is sufficient in order to reproduce?

java.lang.NullPointerException
	at org.eclipse.objectteams.otdt.internal.ui.text.correction.MappingProposalSubProcessor.createMethodSpec(MappingProposalSubProcessor.java:404)
	at org.eclipse.objectteams.otdt.internal.ui.text.correction.MappingProposalSubProcessor.createCalloutFromInferred(MappingProposalSubProcessor.java:395)
	at org.eclipse.objectteams.otdt.internal.ui.text.correction.MappingProposalSubProcessor.getMaterializeInferredCalloutsInheritedProposal(MappingProposalSubProcessor.java:322)
	at org.eclipse.objectteams.otdt.internal.ui.text.correction.QuickFixProcessor.process(QuickFixProcessor.java:396)
...
Comment 1 Stephan Herrmann CLA 2011-08-27 10:34:14 EDT 
Put on my radar.
Comment 2 Stephan Herrmann CLA 2011-12-13 15:44:27 EST 
Although I can somewhat narrow down the issue I fail to find a
way to reproduce.

What we know:
- we have a callout binding inferred from an inherited abstract method
  -> this implies that the inherited role method and a corresponding base
      method exist and match in name and all parameter types 
     (I tried with missing types, but then inference will abort)
- we are computing a proposal to materialize that callout
- in l. 395 "mapping.getRoleMethod()" evaluates to null

Most probable track: 
- while parameters were OK, perhaps the return type of role and/or
   base method was unresolved / missing.
- in this case DefaultBindingResolver.getMethodBinding() could possible
  return null, *but only if* (!this.isRecoveringBindings).
- this again is difficult to achieve, perhaps by a JME during 
   CompilationUnitResolver.resolve (would indicate an inaccessible JavaProject)
  *or* an ICE in that method.

Apparently too many unexpected things need to meet to make this 
bug happen, so analysis without a witness gives no definite result.

Closing as WORKSFORME.