Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-dev] canonical way to handle optional dependencies 
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.blewitt@xxxxxxxxx <mailto:alex.blewitt@xxxxxxxxx>> wrote: 

    On 15 Apr 2021, at 14:05, Jonah Graham <jonah@xxxxxxxxxxxxxxxx
    <mailto: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
    _______________________________________________
    platform-dev mailing list
    platform-dev@xxxxxxxxxxx <mailto:platform-dev@xxxxxxxxxxx>
    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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev

Back to the top