Thanks Tom. That is a very interesting option too. Is there a way from the main bundle to know if the fragment is available? In CDT's case "NoLeak" uses "UILeaker".
Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 09:56, Tom Schindl via platform-dev < platform-dev@eclipse.org> wrote: > Hi, > > An option to ban the offending guy from the codebase would be to move > the offending class to a fragment. > > Let's say we have > > MyBundle > + my.class.UILeaker > - methodA(String) > - methodB(String) > - leakMethod(Shell) > > We could refactor it to: > > -----------8<----------- > MyBundle > + my.class.NoLeak > - methodA(String) > - methodB(String) > > MyBundleCompatFragment > + my.class.UILeaker extends my.class.NoLeak > - leakMethod(Shell) > -----------8<----------- > > Your fragment needs to provide a Eclipse-ExtensibleAPI in the MANIFEST, > as the fragment but this would make your bundle free from the optional > requires (the fragment would require the UI stuff) and as Host and > Fragment share the same classloader you could even call package-scoped > APIs from the fragment. > > Tom > > Am 15.04.21 um 15:42 schrieb Jonah Graham: > > 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 <http://www.kichwacoders.com> > > > > > > On Thu, 15 Apr 2021 at 09:36, Alex Blewitt <alex.blew...@gmail.com > > <mailto:alex.blew...@gmail.com>> wrote: > > > > On 15 Apr 2021, at 14:05, Jonah Graham <jo...@kichwacoders.com > > <mailto: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 <mailto:platform-dev@eclipse.org> > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > <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 > > > _______________________________________________ > 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
