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

Bug 326090

Summary: [api] ProfileChangeOperation leaks non-API
Product: [Eclipse Project] Equinox Reporter: DJ Houghton <dj.houghton>
Component: p2Assignee: DJ Houghton <dj.houghton>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: tjwatson
Version: 3.7Flags: tjwatson: pmc_approved+
Target Milestone: 3.7 M3   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Bug Depends on:    
Bug Blocks: 309539    
Attachments:
Description Flags
patch none

Description DJ Houghton CLA 2010-09-23 14:59:05 EDT 
ProfileChangeOperation#getProfileChangeRequest returns the implementing class rather than the interface (IProfileChangeRequest). We need to change this if we intend to make the class internal as per bug 309539.
Comment 1 DJ Houghton CLA 2010-09-23 16:01:41 EDT 
John and I talked about this and this is the scenario:
- we have new API in 3.6: ProfileChangeOperation
- it has a method (#getProfileChangeRequest) which returned a ProfileChangeRequest object
- in 3.6 PCR is internal provisional and marked as @noreference
- so if clients were calling the method, then it would have been an illegal reference.
- there are no references to this method in the SDK. (only in the p2 tests)

We agree the best course of action is to change the method to return the API class (IProfileChangeRequest) and add an entry in the migration guide saying that we are fixing an API leak.

Adding Tom to the CC for PMC approval and comment.
Comment 2 DJ Houghton CLA 2010-09-23 16:15:58 EDT 
Created attachment 179484 [details]
patch
Comment 3 Thomas Watson CLA 2010-09-23 16:24:25 EDT 
+1

If someone was calling getProfileChangeRequest in 3.6, I assume it was valid to assign the value to IProfileChangeRequest?  This way the client code would not have been referencing the internal type.  If so, we should point out in the migration guide that any client code calling this method must be recompiled, even if they were not referencing the internal type. otherwise they will get a no method def found error because of the change in return type.
Comment 4 DJ Houghton CLA 2010-09-23 16:30:55 EDT 
Yep, you are correct. Clients could have called the method and assigned the result to the API class. I have created bug 326100 to address entering this change into the migration guide for 3.7.

Patch released to HEAD.

Closing.