Community
Participate
Working Groups
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.
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.
Created attachment 179484 [details] patch
+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.
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.
