Bug 162370

Summary: MethodVerifier#areReturnTypesEqual is a misnomer
Product: [Eclipse Project] JDT Reporter: Maxime Daniel <maxime_daniel>
Component: CoreAssignee: Maxime Daniel <maxime_daniel>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 Flags: kent_johnson: review+
Version: 3.3   
Target Milestone: 3.3 M7   
Hardware: PC   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 180789    
Attachments:
Description Flags
Suggested fix none

Description Maxime Daniel CLA 2006-10-26 05:24:37 EDT 
The method implementation is not symetrical. What it does is to check whether its parameters have equal return types, or else if the first one has a return type compatible with the one of the second one, under specific conditions (one of these conditions being that the caller be an instance of MethodVerifier15).
Unfortunately, areReturnTypesCompatible already exists...
Hence clarification of the topic is needed before any action is taken.
Comment 1 Maxime Daniel CLA 2007-03-27 10:13:52 EDT 
A couple of remarks:
- the only uses (in JDT Core - but method verifiers are non-API classes) of the existing areReturnTypesCompatible are in implementations of areReturnTypesEqual;
- areReturnTypesEqual is called from inheritance verification code and from areMethodsEqual, which is a misnomer of its own (since it checks whether one method overrides the other and has a compatible return type, which is probably not what 'Equal' suggests).

I would then propose to:
- rename areMethodsEqual to areMethodsCompatible;
- keep the existing areReturnTypesCompatible,
- but implement a new method called  bypassFurtherCompatibilityChecks that would
  introduce the nuance between method verifiers.

Will post a patch along those lines.
Comment 2 Maxime Daniel CLA 2007-03-29 03:48:46 EDT 
Created attachment 62357 [details]
Suggested fix

After playing a bit with the code, I preferred to delegate part of the check to a worker method (suffixed by 0) when needed only. With this patch, areReturnTypesCompatible always returns immediately if types are identical, or else selectively (depending on compatibility levels) proceed with further checks.

Kent, please let me know what you think.
Comment 3 Maxime Daniel CLA 2007-04-17 10:33:54 EDT 
Released for 3.3 M7.
Comment 4 Olivier Thomann CLA 2007-04-27 11:19:32 EDT 
Verified for 3.3M7 using I20070427-0010