First understand that Jigsaw’s primary use case is to modularise the JRE itself. As a secondary goal it will offer a module system that may be used by other Java libraries and applications.
My position is that something like Jigsaw is probably necessary for the JRE only, but that it will create far more problems than it claims to solve if used by other Java libraries or apps.
The JRE is a very difficult and special case. It is over 12 years old and is a frightful mess, riddled with dependency cycles and nonsensical dependencies. At the same time is is used by approximately 9 million developers and probably billions of running systems. Therefore you absolutely cannot refactor the JRE if that refactoring creates breaking changes.
OSGi is a module system that helps you (or even forces you to) create software that is modular. You cannot simply sprinkle modularity on top of an existing non-modular codebase. Making a non-modular codebase into a modular one inevitably requires some refactoring: moving classes into the correct package, replacing direct instantiation with the use of decoupled services, and so on.
This makes it hard to apply OSGi directly to the JRE codebase, yet we still have a requirement to split the JRE into separate pieces or “modules” so that cut-down versions of the JRE can be delivered.
I therefore regard Jigsaw as a kind of “extreme measure” to keep the JRE code alive while splitting it up. It does not help code to become more modular, and I’m convinced that it will actually increase the maintenance required to evolve any library or application that uses it.
Finally: OSGi exists whereas Jigsaw does not exist yet and may never exist. The OSGi community has 12 years of experience in developing modular applications. If you are seriously interested in developing modular applications, OSGi is the only game in town.