Thanks Alex for the insights. This is one of those APIs that I don't think is used in practice (but you can never be sure). CDT adopted the same API deletion process as Platform, so we can delete it without the major version bump. Therefore using new methods may be a good solution to handle the period between deprecation and deletion.
Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 09:36, Alex Blewitt <alex.blew...@gmail.com> wrote: > On 15 Apr 2021, at 14:05, Jonah Graham <jo...@kichwacoders.com> 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 > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
