My two-penneth. Thanks to people like PK, IBM and others - OSGi has SO MANY things right.
OSGi Alliance didn’t get this correctly day one - but the ability to evolve Specifications over 2 decades is unheard of and more more important than the vast majority of people in the IT industry realises. OSGi will interoperate with JPMS just fine. I’ve faith that that the OSGi Alliance will ensure this. And from my perspective - a CEO of a company 100% committed to OSGi - I am more optimistic in 2018 than perhaps at any other time. Taking a strategic view - the software industry is collapsing under fragmentation and software technical debt. OSGi remains the only approach to addressing these issues. Anyone trying to build a sophistication eco-system of software services using JPMS / REST Microservice / Containers are in for a world of pain. The OSGi Alliance will continue to push forwards. Keep your eyes open for interesting developments later in 2018. Happy to talk off list to any / all about specific concerns. Best Wishes Richard p.s. Peter <j...@zeus.net.au> - good to see you on the list! > On 13 Apr 2018, at 09:32, osgi-dev-requ...@mail.osgi.org wrote: > > Send osgi-dev mailing list submissions to > osgi-dev@mail.osgi.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.osgi.org/mailman/listinfo/osgi-dev > or, via email, send a message with subject or body 'help' to > osgi-dev-requ...@mail.osgi.org > > You can reach the person managing the list at > osgi-dev-ow...@mail.osgi.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of osgi-dev digest..." > > > Today's Topics: > > 1. Competing module systems (Mark Raynsford) > 2. Re: Competing module systems (Peter Kriens) > 3. Re: Competing module systems (Mark Raynsford) > 4. Re: Competing module systems (Peter) > 5. Re: Competing module systems (Neil Bartlett) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Apr 2018 18:06:38 +0000 > From: Mark Raynsford <list+org.o...@io7m.com> > To: osgi-dev@mail.osgi.org > Subject: [osgi-dev] Competing module systems > Message-ID: <20180412180638.669a0...@copperhead.int.arc7.info> > Content-Type: text/plain; charset="us-ascii" > > Thought this might be of mild interest to people on this list: > > https://blog.io7m.com/2018/04/12/competing-module-systems.xhtml > > -- > Mark Raynsford | http://www.io7m.com > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 228 bytes > Desc: OpenPGP digital signature > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20180412/e8641958/attachment-0001.sig> > > ------------------------------ > > Message: 2 > Date: Thu, 12 Apr 2018 20:32:13 +0200 > From: Peter Kriens <peter.kri...@aqute.biz> > To: Mark Raynsford <list+org.o...@io7m.com>, OSGi Developer Mail List > <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Competing module systems > Message-ID: <9dfed6fd-f68e-4d9e-9285-8a5854060...@aqute.biz> > Content-Type: text/plain; charset=utf-8 > > Caught between a rock and a hard place with only one way forward ? > > Oracle?s strategy is a mystery to me. > > Kind regards, > > Peter Kriens > >> On 12 Apr 2018, at 20:06, Mark Raynsford via osgi-dev >> <osgi-dev@mail.osgi.org> wrote: >> >> Thought this might be of mild interest to people on this list: >> >> https://blog.io7m.com/2018/04/12/competing-module-systems.xhtml >> >> -- >> Mark Raynsford | http://www.io7m.com >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > ------------------------------ > > Message: 3 > Date: Thu, 12 Apr 2018 21:12:19 +0000 > From: Mark Raynsford <list+org.o...@io7m.com> > To: Peter Kriens <peter.kri...@aqute.biz> > Cc: OSGi Developer Mail List <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Competing module systems > Message-ID: <20180412211219.61c66...@copperhead.int.arc7.info> > Content-Type: text/plain; charset="utf-8" > > On 2018-04-12T20:32:13 +0200 > Peter Kriens <peter.kri...@aqute.biz> wrote: > >> Caught between a rock and a hard place with only one way forward ? > > I should make the point that I don't hate the JPMS. I do think that > it's just barely the minimum viable product, though. > > The JVM really did need a module system, both for the maintenance of > the JDK itself and the future features that the system enables. > >> Oracle?s strategy is a mystery to me. > > I think their strategy is fairly explicable, but I think they did make > some mistakes with some of the specifics (filename-based automodules!). > There's a pattern that Oracle tend to follow: They solicit opinions from > everyone vigorously, and then they implement the smallest possible > subset such that the fewest possible people are pissed off by it. If > there's a possibility of doing something wrong, nothing is done > instead. Being incomplete and "too strict" is considered preferable to > any kind of maintenance burden or making a mistake that people then > come to depend upon. Then, after a version of something is released, > the dust settles and the people that are still complaining after a year > or so of implementation are asked for comments again. The process > repeats! You can see this going on with quite a few of their projects. > A good example of this with the JPMS is that there was a vigorous > insistence that the module graph be a DAG. Now, some way into the first > year, it's going to be allowed to be cyclic but only at run-time. I > think the process does eventually produce results, but it takes a long > time to get there and demands a lot of patience from the people > involved. Most VM features seem to start off utterly spartan and then > grow to support the use-cases that people wish they'd supported right > from the start. > > Java in particular has awful press, and a userbase that seems to become > incomprehensibly enraged over all good news and all bad news > indiscriminately, so that doesn't help the perception of the process > (or the results). > > I think the key will be to continue complaining for as long as it takes > to get better interop between OSGi and the JPMS. :) > > -- > Mark Raynsford | http://www.io7m.com > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 228 bytes > Desc: OpenPGP digital signature > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20180412/8298efa7/attachment-0001.sig> > > ------------------------------ > > Message: 4 > Date: Fri, 13 Apr 2018 17:51:21 +1000 > From: Peter <j...@zeus.net.au> > To: osgi-dev@mail.osgi.org > Subject: Re: [osgi-dev] Competing module systems > Message-ID: <5ad06179.3090...@zeus.net.au> > Content-Type: text/plain; charset=UTF-8; format=flowed > > That's a pretty good summary of it. > > Personally, I would have preferred they only use it for the JVM. JPMS > doesn't grok versioning and the jvm doesn't generally break backward > compatibility, so it's ok there, I don't think there will be a lot of > external adoption anyway. > > Cheers, > > Peter. > > On 13/04/2018 7:12 AM, Mark Raynsford via osgi-dev wrote: >> On 2018-04-12T20:32:13 +0200 >> Peter Kriens<peter.kri...@aqute.biz> wrote: >> >>> Caught between a rock and a hard place with only one way forward ? >> I should make the point that I don't hate the JPMS. I do think that >> it's just barely the minimum viable product, though. >> >> The JVM really did need a module system, both for the maintenance of >> the JDK itself and the future features that the system enables. >> >>> Oracle?s strategy is a mystery to me. >> I think their strategy is fairly explicable, but I think they did make >> some mistakes with some of the specifics (filename-based automodules!). >> There's a pattern that Oracle tend to follow: They solicit opinions from >> everyone vigorously, and then they implement the smallest possible >> subset such that the fewest possible people are pissed off by it. If >> there's a possibility of doing something wrong, nothing is done >> instead. Being incomplete and "too strict" is considered preferable to >> any kind of maintenance burden or making a mistake that people then >> come to depend upon. Then, after a version of something is released, >> the dust settles and the people that are still complaining after a year >> or so of implementation are asked for comments again. The process >> repeats! You can see this going on with quite a few of their projects. >> A good example of this with the JPMS is that there was a vigorous >> insistence that the module graph be a DAG. Now, some way into the first >> year, it's going to be allowed to be cyclic but only at run-time. I >> think the process does eventually produce results, but it takes a long >> time to get there and demands a lot of patience from the people >> involved. Most VM features seem to start off utterly spartan and then >> grow to support the use-cases that people wish they'd supported right >> from the start. >> >> Java in particular has awful press, and a userbase that seems to become >> incomprehensibly enraged over all good news and all bad news >> indiscriminately, so that doesn't help the perception of the process >> (or the results). >> >> I think the key will be to continue complaining for as long as it takes >> to get better interop between OSGi and the JPMS. :) >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > ------------------------------ > > Message: 5 > Date: Fri, 13 Apr 2018 09:32:30 +0100 > From: Neil Bartlett <njbartl...@gmail.com> > To: Mark Raynsford <list+org.o...@io7m.com>, OSGi Developer Mail List > <osgi-dev@mail.osgi.org> > Subject: Re: [osgi-dev] Competing module systems > Message-ID: > <CAPr=90M7h61V=bNUa79Pqvvo3t9g80-C3VJuc=gbs5_zlym...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Apr 12, 2018 at 10:12 PM, Mark Raynsford via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > >> On 2018-04-12T20:32:13 +0200 >> Peter Kriens <peter.kri...@aqute.biz> wrote: >> >>> Caught between a rock and a hard place with only one way forward ? >> >> I should make the point that I don't hate the JPMS. I do think that >> it's just barely the minimum viable product, though. >> >> The JVM really did need a module system, both for the maintenance of >> the JDK itself and the future features that the system enables. >> >>> Oracle?s strategy is a mystery to me. >> >> I think their strategy is fairly explicable, but I think they did make >> some mistakes with some of the specifics (filename-based automodules!). >> There's a pattern that Oracle tend to follow: They solicit opinions from >> everyone vigorously, and then they implement the smallest possible >> subset such that the fewest possible people are pissed off by it. If >> there's a possibility of doing something wrong, nothing is done >> instead. > > > While I've seen that principle operate at other times (remember how > controversial erasure was in Java 5?), I'm not sure it's worked that way in > the JPMS case. In fact JPMS does far more than it needed to. > > The key feature of JPMS that could not be achieved before, even with > ClassLoaders, was strictly enforced isolation via the accessibility > mechanism, as opposed to the visibility mechanism that is employed by OSGi. > That strict isolation was needed primarily to allow Oracle to close off JVM > internals from application code and thereby prevent a whole class of > security vulnerabilities. Remember that Oracle was being absolutely > slaughtered in the press around 2011-12 over the insecurity of Java, and > most corporates uninstalled it from user desktops. > > But they could have achieved this with a thin API, comparable to > ProtectionDomain. If they had done that then OSGi (and other module systems > like JBoss) could have chosen to leverage the API to enforce strict > separation between OSGi bundles. > > But they didn't do that. Instead they implemented a whole new, incompatible > module system with its own metadata format, including changes to the Java > language spec. Then they restricted the ability to apply strict isolation > to artifacts that are JPMS modules. With the thin API they could have still > built their own module system on top, following their own ideas of how > modules should work, and competed with OSGi on a fairer playing field. > > > >> Being incomplete and "too strict" is considered preferable to >> any kind of maintenance burden or making a mistake that people then >> come to depend upon. Then, after a version of something is released, >> the dust settles and the people that are still complaining after a year >> or so of implementation are asked for comments again. The process >> repeats! You can see this going on with quite a few of their projects. >> A good example of this with the JPMS is that there was a vigorous >> insistence that the module graph be a DAG. Now, some way into the first >> year, it's going to be allowed to be cyclic but only at run-time. I >> think the process does eventually produce results, but it takes a long >> time to get there and demands a lot of patience from the people >> involved. Most VM features seem to start off utterly spartan and then >> grow to support the use-cases that people wish they'd supported right >> from the start. >> >> Java in particular has awful press, and a userbase that seems to become >> incomprehensibly enraged over all good news and all bad news >> indiscriminately, so that doesn't help the perception of the process >> (or the results). >> >> I think the key will be to continue complaining for as long as it takes >> to get better interop between OSGi and the JPMS. :) >> > > Interop already works just fine in one direction: OSGi bundles depending on > JPMS modules, with a combination of the changes in R7 to export java.* > packages from the system bundle and some creative use of > Provide/Require-Capability. But bidirectional interop will likely always be > impossible or very hard, because JPMS modules are only allowed to depend on > JPMS modules. This was clearly a deliberate strategy to tilt the table > towards JPMS, but it may be backfiring since -- as you've pointed out -- > applications can only migrate to modules when all of their dependencies are > modules, including third party libraries, and the migration of libraries > has been exceedingly slow. > > Neil > > >> >> -- >> Mark Raynsford | http://www.io7m.com >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.osgi.org/pipermail/osgi-dev/attachments/20180413/5e3a6005/attachment.html> > > ------------------------------ > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > End of osgi-dev Digest, Vol 138, Issue 4 > **************************************** _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
