IntelliJ also has modules. 😉
1. How is this similar and different from modularization provided by Maven and OSGi (though these may not be comparable per se but I wanted to understand from an analogy point of view)
The central aspect all of these modules have in common is that they are centered around one JAR and (usually) one source tree:
in IntelliJ, a module usually contains a single source treea Maven module compiles, tests, and packages a single source tree (usually) to a JARfor the module system at compile time, a single module-info.java, which is usually bound to a single source tree, defines a modulefor the module system at run time, a single JAR defines a modulefor OSGi, a single JAR defines a bundle
All of these modules also deal with dependencies and JPMS and OSGi also manage API access. But that's mostly what they have in common. As soon as you get into the details, things differ a lot. Yes, Maven and JPMS manage dependencies, but the former cares about versions, downloads artifacts, and places them on class and module path, whereas the latter simply takes that as input. Yes, JPMS and OSGi manage API access, but the former operates below class loaders and limits accessibility whereas the latter operates on top of class loaders (in fact, that's how OSGi is implemented) and limits visibility. We could go on like this.
So while it makes sense that all of these tools call the "bag of code" they're working on a "module", the term means different details for each. And that's perfectly ok because each tool has different tasks and thus needs different pieces of information to to fulfill them. While it's not entirely coincidental, we're actually pretty lucky that all of these tools agree on the "1 source tree : 1 JAR : 1 module" relationship, so the term "module" does not mean radically different things in different contexts.
2. Will these technologies work together and strengthen the notion of modules or do you think they are incompatible?
While OSGi is a very mature system, it's tool support is far from ubiquitous. It's usually implemented via plugins for IDEs and build tools and users who don't use OSGi don't get in touch with them. Given OSGi's market share that means few developers get in touch with these tools and can use them to learn about their code.
I really hope this will be different for the module system. It's build into the Java platform's core and everybody interacts with it at least via the unnamed module. Starting to modularize from there will be a fairly natural process and so I hope many teams will do it, which will in turn make tool vendors improve their support. That gives me hope that the ecosystem will strengthen its notion of modules, that tools will converge on a shared understanding, making it easier for developers to think of their projects in these terms.
But we're definitely not there yet. I recently created a JPMS maturity model
that lets us compare module system support by various tools and it makes obvious how much their level of support still differ.