• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Bear Bibeault
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh

The Java Module System - analogies elsewhere

 
Ranch Hand
Posts: 49
Android Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A very warm welcome to you Nicolai!

My question is around the conceptual analogy of modules in other platforms / tools such as Maven or OSGi. What I would like to know is:

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)
2. Will these technologies work together and strengthen the notion of modules or do you think they are incompatible?
 
Greenhorn
Posts: 17
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 tree
  • a Maven module compiles, tests, and packages a single source tree (usually) to a JAR
  • for the module system at compile time, a single module-info.java, which is usually bound to a single source tree, defines a module
  • for the module system at run time, a single JAR defines a module
  • for 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.

     
    You showed up just in time for the waffles! And this tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    reply
      Bookmark Topic Watch Topic
    • New Topic