why-service-tracker-is-not-bad

[laeubi]

but only used wrong if lazy activation is not desired.

[alblue]

Thanks for the PR, but I won't merge it for the following reasons:

• The point of this repo is to show that with a simple "out of the box" usage of ServiceTracker has potential unintended side effects
• The existing links to this repo are against the current version of the code, not subsequent changes
• The code is significantly more complex and unlikely to be used in practice

That's not to say I disagree with your code or that by tracking ServiceReference you can defer construction of those services until runtime. But it's not appropriate for this repository, which is showing how simple uses of ServiceTracker is bad.

An analysis of the existing Eclipse ecosystem shows that the vast majority of ServiceTrackers do not use a ServiceTrackerCustomiser to track ServiceReferences, and in addition, may not store the BundleContext necessary to restore the ServiceReference to a service on demand.

And honestly, if you're just tracking a single ServiceReference like this (rather than a Service) you would probably be better off using the ServiceCaller, which looks like:

ServiceCaller.callOnce(getClass(),Runnable.class, (r) -> { r.run(); });

I will however update my blog post and link back to this PR as an indication of how you can achieve the same effect with more complex code using ServiceTracker, so thanks for the code example!

[laeubi]

Your blog-post suggest that

Unfortunately, there’s no way to use ServiceTracker to listen to lazily activated services
, and as an OSGi standard, the behaviour is baked in to it.

and this is simply wrong, and I just wanted to show that, no need to merge it, and I assume that its an uncomman case to register a runnable anyways.

But it's not appropriate for this repository, which is showing how simple uses of ServiceTracker is bad.

So what do you really want to sho in your blog-post? It indicates that something is bad with servictracker that is simply not the case, your usage in the example is simply bad so why to blame servicetracker for this?

There might be times where you want to lazy consume a service, then neither DS nor service tracker support this case without additional code.

Or you need the service, then servicetracker and DS do behave exactly the same (you don't need to create service trackers in the activator!)