Latest @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
Java, the OLPC, and community responsibility
The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
com.icu to be removed as a dependency for RCP?
At 5:18 PM on Apr 25, 2007, Alex Blewitt
wrote:
Until recently, the help bundle has expressed a dependency on com.icu (in either form), but now this dependency has been removed. It's still a work-in-progress, but bug 183761 has been marked FIXED for 3.3M7, so now it is no longer required by any bundles in the RCP package.
Of course, the full unicode components are likely to be required for the standard SDK/JDT bundles, but the point is that developers wishing to build their own apps on top of RCP can now use a smaller set of components for delivering their data.
The wiki page also notes that the eRCP project, whilst it has been designed for lower-powered devices, still works on the Windows platform and only takes up 4MB of runtime.
4 replies so far (
Post your own)
Re: com.icu to be removed as a dependency for RCP?
That is a nice change especially for RCP developers.Re: com.icu to be removed as a dependency for RCP?
Boris highlights the fact that dependencies on the actual bundle (com.icu) should be avoided, and instead Import-Package used instead, so that substitution of the full com.icu bundle with the cut-down stub can happen in comment 8 of that bug.The workbench still needs the com.icu package (whether the full 4Mb or the 100k stub) but it still helps to reduce the size of the RCP framework.
Alex.
Re: com.icu to be removed as a dependency for RCP?
Using Import-Package how do you make sure that you are not depending on a package that is not fully public? In the past I have seen cases when using Import-Package the runtime chose a bundle in one of the internal packages of eclipse and Eclipse complained that the mentioned bundle is not accessible. Or was this only because there was no other public package available so the runtime resorted to the internal one?Re: com.icu to be removed as a dependency for RCP?
The packages exported by internal code have x-internal:=true on the export. I'm pretty sure that the PDE (or build) will generate warnings if you try and use them, but will otherwise bind to that package.It's really something that gets enforced at compile-time rather than run-time. It's only if the package doesn't get exported at all that OSGi hides it; in this case, the package is 'public, but don't tell anyone' rather than 'private'.
Re either/or bundles; if those bundles do Import/Export of the package, then you can have a valid split bundle. If two bundles Export (but don't Import) then you can end up with a random resolution to one of them (both may not work). In this case, x-internal doesn't have any effect on the preference; and I'm not sure that the preference is determinsitic, at least betewen runs (probably lowest numbered bundle id or something like that).
See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html for a more detailed look at it ...
Alex.