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

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@xxxxxxxxxxx> 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.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
>
_______________________________________________
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