[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] canonical way to handle optional dependencies
|
On 15 Apr 2021, at 14:05, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
>
> Most of the dependencies on the UI are relatively easy to resolve. However one area is in the API - the API includes references to org.eclipse.ui.dialogs.IOverwriteQuery, and in the headless case these references are null.
The problem is that if it is part of the API (ie method argument, return value) then the class has to be loaded in order to call that method, even with a null value. If you attempt to call this method then it will attempt to load the ui class and when it’s not found it will raise a ClassNotFound error (or similar).
In order to fix it you’ll need to change the API to take a more generic object (like Object) which will allow you to call the method with a null value, and you can pass through the untyped value to where it needs to be used, casting it at the point of use (or using a reflective call that obscure the types).
You may find the right evolution path is to create a second method with the same signature but using Object in place, migrating the code paths to that method, and leaving a call path from the old to the new. You can then mark the old API as deprecated and invite callers to move over to the new call.
Using the same method name has both advantages and disadvantages; if you are calling with null then you’ll need to disambiguate by casting to Object but might facilitate changeover when you delete the old method; if you use a new name then callers will have to change source code to take advantage of the changed api but will likely be easier to determine if code has been moved from old to new patterns.
In either case it is a new method signature which won’t be source compatible for old callers, so it’s probably a major version bump when you remove the old call path.
Alex
