On 2017-07-22T17:46:56 +0100 Neil Bartlett <njbartl...@gmail.com> wrote: > > On 22 Jul 2017, at 14:23, Mark Raynsford <list+org.o...@io7m.com> wrote: > > > > Yes, as am I. I used the example of multiple versions of the same jar > > resulting in multiple conflicting registrations of services trying to > > use the same name because having multiple versions of the same jar is > > the primary "error" case where this can happen. If we ignore the case > > where two unrelated jars or bundles publish services that just happen > > to pick conflicting names, then that just leaves us with the case where > > two versions of the *same* jar attempt to publish services with > > conflicting names. > > But why ignore that case? It’s the primary problem. As you said, the case of > having multiple versions of the same module already has some protections > around it — in fact it’s only really possible in OSGi.
That probably should have read "if we ignore the case (for the purposes of this discussion)". We can't ignore it in practice for the reasons stated by you and others (including myself). > > So, with that in mind: In Java < 9, having multiple versions of the > > same jar on the classpath is discouraged and considered to be bad > > practice, so this situation is _possible_ but _somewhat less likely_ to > > occur with ServiceLoader. In Java 9, there are VM-level checks in place > > to prevent conflicting modular jars from being loaded, so this > > particular error case can't happen. In OSGi however, as I said, it's > > possible if not encouraged to have two different versions of a bundle > > installed, so this error case *can* occur. That's not a disadvantage of > > OSGi at all, quite the opposite, but it does mean that classes that do > > that kind of centralized registration of services have to be able to > > cope with it. > > I don’t know what kind of VM-level checks you’re talking about here, and as > one of the experts on the JSR 376 Expert Group, I suppose that I really > should know. I was referring to the fact that if two modular jars export the same package, the VM won't allow them to coexist in the same ModuleLayer. I was working from the assumption that, if a given module M exports a package P and a service S, then another version of M (call it M') will probably export the same package P, and therefore M and M' can't coexist. My point was that, in the common case, Java 9 would probably prevent that specific error case as a side effect of the export restrictions. I'm well aware that modules aren't required to export any packages, but I imagine it's going to be quite a while before that becomes recognized as a best practice. :) > I think you may also be touching on the philosophical difference between a > service and a library in OSGi. > > There are some degrees of grey between these opposites, such as when you > request an ImageFormatter with a specific name, or a MigestDigest with a > specific algorithm, etc. Yeah, I understand and appreciate all of the things you mentioned. It's this grey area that prompted the original email. As I said, (and I think we're beating a dead horse somewhat, I've restated this repeatedly), I was asking how experienced OSGi developers would handle implementing an API like ImageIO.read() (not how they'd replace it with a much better API that's OSGi-aware), and that question has been answered to my satisfaction! -- Mark Raynsford | http://www.io7m.com
pgps7hnlgL9mW.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
