Unfortunately most frameworks export the tracker package directly, rather than from a separate bundle, despite it not being part of the core spec.
BJ, what's to stop a framework providing an optimised ServiceTracker implementation? The tracker package is very odd in that OSGi directly provides the implementation rather than just specifying behaviour... Neil On 14 January 2014 at 19:09:17, Raymond Auge ([email protected]) wrote: Why not provide two different impls? Same API, different Bundle-RequiredExecutionEnvironment. With no difference in the external APIs you're not breaking the portability of user's code. Obviously concurrency is far less of a problem in embedded. But on the server side actually the opposite is true? Maintenance is certainly a hassle, but it's an issue where serving two masters means neither can be completely satisfied. - Ray On Tue, Jan 14, 2014 at 1:47 PM, BJ Hargrave <[email protected]> wrote: > Even for getTracked, the method returns a writeable, sorted map, so > it must be a sorted copy of the internal map. If there was a > SortedCopyOnWriteMap class, this could be used for the internal map > to make the copy an O(1) operation but at the cost of making all map > mutations more expensive. So it may be a bad tradeoff for many. I will note that we could use ConcurrentHashMap here. The copy would not be O(1) since the sorting must still take place, but it would require no synchronization during the copy. However, this requires Java 5 and the tracker package still works on Java ME for our embedded users of OSGi. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
