I am sorry, but I am not going to worry about a few hundred K or even a few
megabytes of memory because nobody else seems to be doing this anymore.
Virtually all code I see is compiled with debug info, doubling the size of
bundles. An XML file is 5x times the in-memory size over the corresponding
source file. Just the amount of memory people spent on logging is dwarfing
these kind of costs. And in this case, the low cohesiveness of util bundles is
usually dragging in MUCH more overhead in unnecessary dependencies than it
costs. I am pretty sure that given some time I could reduce the average plugin
to half its size. Anyway, as always, you have to know what you're doing, it is
a trade off.
If a utility provides an abstraction it seems more suitable to be a service.
E.g. an Eclipse FileService could easily provide the abstractions you need, and
even some utility functions. I am not arguing for a Path service, that seems
too fine grained, but a service that abstracts the file system (which you're
doing in Path) sounds like good design, the Path class can then be a utility in
that service package.
I can give you a list of utils I automatically include in bnd
aQute.lib.base64 encoding/decoding base 64
aQute.lib.collections simple collection helpers
aQute.lib.filter OSGi filter impl
aQute.lib.hex encoding/decoding hex
aQute.lib.index tiny file btree impl
aQute.lib.io IO utilities
aQute.lib.tag XML generation
aQute.libg.cafs content addressable file system
aQute.libg.command External execution
aQute.libg.cryptography helpers for JCE
aQute.libg.fileiterator line iterator over files
aQute.libg.generics makes creating generic collections easier
aQute.libg.header OSGi header parsing
aQute.libg.qtokens A StringTokenizer that handles quoted strings
aQute.libg.sed Replaces strings in files based on patterns
aQute.libg.version A version and version range
aQute.libg.xslt makes XSL easier to use
In bndtools Neil even includes the whole bnd because I do not want to provide a
public API to bnd that I keep stable. Maybe one day I will provide a service
API but I just do not want to do that now. So including bnd in bndtools is
therefore a perfect solution, nobody can depend on those classes.
Making this list gave me some more criteria. I think a util is where you
simplify using an invariant. You can't change base64 so encoding and decoding
base64 is a good utility. Providing an IO class that makes the streams easier
to use is not abstracting, it is just reducing the number of lines you have to
write each time you want to copy a file to a stream. It is painfully simple
code but you just have to repeat it over and over. If your Path class is really
clever and hides details it really might not be just a utility but more part of
an important abstraction. Notice that in OSGi services are always defined in
packages, allowing you to provide helpers to make a service easier to use.
Kind regards,
Peter Kriens
On 2 dec 2010, at 15:59, Jeff McAffer wrote:
>> Note that Conditional-Package does NOT create source redundancy. Any bug
>> that creeps up and fixed is automatically fixed next time the bundle is
>> build (and tested). Really, the problem you sketch is non-existent. On the
>> contrary, in my experience it increases robustness. Instead of finding the
>> new util jar in runtime you test the bundle using the Conditional-Package
>> with the exact version you'll deploy.
>
> One of the touted benefits of OSGi and version ranges etc is that you can
> pick up new things as they come available and do not have to ship monolithic
> wads. Promoting the "put your prereqs in your bundle" approach seems counter
> to that model. What do you see as the difference?
>
> As for the problem being non-existent... I accept that "in your experience"
> it has not been a problem. However, I've seen people use other approaches
> because they see it as a problem. Acceptability is in the eye of the
> beholder. I agree that the "copy the binaries" approach works perfectly fine
> in many situations. As does the fine grained bundle approach and, heaven
> forbid, the common/util bundle approach.
>
>> You point out a subtle difference between a util and an interoperability
>> standard. Utility classes with Conditional Package must not appear in the
>> public API of the bundle because each bundle has its own binary copy. A util
>> is supposed to do some repetitive work, not provide important abstractions.
>> Those are services.
>
> You are making a particular assumption about the definition of "utility
> class". Is the expectation that util classes never appear in API? It's not
> clear that everyone on this thread is working with that assumption (might
> just be me who is/was not). Perhaps the definition should be flipped around.
> util classes are, defintion, the things that a bundle uses that do not appear
> in their api and the bundle author did not write? That seems useful but
> pretty narrow.
>
> As for abstraction and service-ness, I know where you are going but you
> skipped over a whole mess of important classes like String, Path, <and more
> complex datatypes> ... that provide important abstractions/function (some
> would even say "utility") but few would argue should be services. These may
> or may not appear on the API of various bundles. If they do then we have to
> be careful about maintaining the class space and we still have the open
> question about how to bundle them.
>
> For example, if every Eclipse bundle that used Path had its own copy we would
> have hundreds of copies on disk and many of these would be in memory (if the
> bundle does not import). The class is say about 20K. Thats just one example
> but it already points to potentially megabytes of wasted memory.
>
> In the end a lot depends on the numbers. How many util classes? How big are
> they? How many consumers? How many used in API (thus imported)? How often to
> they change? How many users are in your control?
>
> Jeff
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
