I'm not sure you ever got answers to some
of your questions ... so, just in case you still need them ....
> I noticed long ago that MANIFEST.MF as shipped by
> little resemblance to my source text. There is a nasty line-wrapping
> and every class has an SHA1-Digest added.
The "wrapping" is part of the "spec"
for MANIFEST.MF files and any build and any runtime version should be wrapped
that way (that is, not exceed 80 characters ... how old is that! :)
The SHA Digest is part of the "code signing"
that occurs ... again, any build that "signs" would have these.
So, these first two aren't specific to Eclipse, OSGI,
or Sim. Release, or anything other than "Java".
> If something is rewriting all the Import-Package directives, then
> surely it could/should rewrite all the Export-Package directives to
> use "uses" too?
There are actually some "build
tools" that will do that, such as BND ... I think its called ... and
not sure if by default, or if you have to spell it out ... BUT, we discussed
this in Orbit (at least in Orbit, other projects may have also) and decided
against a blanket "always use uses-clauses" because there was
some concern that if it was ALWAYS used, then it would start to have a
performance impact ... not so much for "small apps" of several
hundred bundles ... but, for cases where several thousand bundles were
being used, it might start to add up, especially to start-up time, and
especially to "first time" start-up time. That was many many
years ago, so not sure if there has been any studies or improvements in
that concern. But, it is also clear that in some cases, it is definitely
required, to get components to "play nice" with each other. I'm
sorry I don't know of a clear statement of "how to know" when
its required, and when its not ... but if there is one, I bet a search
engine would find it. (including some interesting, old, bug reports :)
Ed Willink <ed@xxxxxxxxxxxxx>
Cross project issues
06/04/2014 07:21 AM
Pseudo-singleton for Guava in RC3
On 04/06/2014 11:48, David M Williams wrote:
> I think that someone with the power to influence the platform needs
to review how
> we support Guava and other shared non-singletons
> so that we avoid repeating this mess in Mars.
Hmmm, I think, Ed, I finally found one thing to disagree with you about
Hopefully we're agreed about trying to avoid this mess
in Mars. If tooling rather than the platform is the solution, fine by me.
I think if you (or others) carefully read Bug
427862 you'd find this issue less about
"using one version" and more about using correct versions, in
correct ways: a) projects should follow "best practices"
for componentization (such as, 1) do not "re-export" bundles
simply for a convenience, 2) don't make "third party" code part
of your own API (unless it's one that's mature, and one that can be well
trusted to follow OSGi principles), 3) use proper version ranges when exporting
or importing packages, 4) take advantage of "uses clauses", etc.)
and b) we need to influence those third parties who are not using OSGi
quite right, and encourage them to do so (which has happened, in this case!)
Thanks for pointing back at this. I didn't understand
"uses" and got Marcel to give a better example.
I see that the Manifest editor has a "Calculate Uses" button
that makes my Manifests huge. I don't particularly want to maintain this
I noticed long ago that MANIFEST.MF as shipped by SimRel bears little resemblance
to my source text. There is a nasty line-wrapping and every class has an
If something is rewriting all the Import-Package directives, then surely
it could/should rewrite all the Export-Package directives to use "uses"