17 responses to “Modules, modules, modules …”

• 

  RR August 31st, 2011 at 00:44

  package objects as module interface definition.

  http://www.scala-lang.org/docu/files/packageobjects/packageobjects_3.html

• 

  Adam Warski August 31st, 2011 at 08:42

  Interesting, though right now package objects don’t have any substantial differences to classes nested inside scala objects, if I’m not mistaken.
  But the comments about how the package objects may evolve are certainly promising :)

  Thanks,
  Adam

• 

  Papapetrou Patroklos August 31st, 2011 at 20:55

  Nice article althought I dont’a agree with everything.

  I have posted a similar article wondering why there is not standard for developing modular web applications
  http://onlysoftware.wordpress.com/2011/07/19/why-there-is-no-standard-for-developing-real-modular-web-applications/

• 

  Stephen Colebourne September 1st, 2011 at 17:54

  See pods in the Fantom language for the JVM.
  http://fantom.org/doc/docLang/Structure.html
  http://fantom.org/doc/docLang/Deployment.html

  Each pod is a module. You can only compile modules (you can’t compile classes). Pods store full dependency information and can provide compile and runtime protection. Plus a full database of all the types they hold (easy lookup by class/mixin name or annotation/facet). And soon to be released is the shared repo http://fantom.org/doc/docFanr/index.html

  Overall, a top quality module system!

• 

  Yardena September 1st, 2011 at 18:28

  Re your question in the end of the post – have you looked at Newspeak? http://gbracha.blogspot.com/search/label/Modularity

  There’s also a paper http://www.bracha.org/newspeak-modules.pdf

• 

  Caspar MacRae September 2nd, 2011 at 13:07

  Question: “All of the problems from Maven modules are inherited”?

  First maven & OSGi have a certain synergy, but OSGi “inherits” nothing from maven.

  If you only mean managing dependencies and their versions? Then I see your problems as actually the solutions – you really do have to manage these in any modular environment, they cannot be ignored.

  But if not, please clarify eaxctly what these “problems” are …

• 

  Adam Warski September 2nd, 2011 at 14:31

  Of course OSGi doesn’t “inherit” from Maven anything technologically, but the conceptual problems stay the same; for example – when to factor out a functionality to a separate bundle, when is it big enough? How about naming? You still have to name the bundle, the packages inside and the classes.

  Adam

• 

  Adam Warski September 2nd, 2011 at 14:38

  Looks nice! So if I understand correctly:
  * there are no java-style (nested) packages, only top-level pods (though they can be named com.company.anything, but there’s no subpod-pod relation concept)
  * pods integrate with the build & deployment system
  * compile-time protection, no run-time isolation (?)

  What about “DI”? Can I say that I depend on some pod which implements a given interface?

  This, in fact, brings us to the crucial concept of module interface and module implementation, which I didn’t cover in the blog post (see OCaml of example). So here we would need interface and implementation pods.

  Adam

• 

  candide September 2nd, 2011 at 14:42

  Sorry but I could not understand the refactoring problem in Maven module example.
  Moreover I could not understand ” All of the problems from Maven modules are inherited … with the additional need to name the bundle!” in the OSGi part.

  Could you clarify a bit more ? I’m not expert in the area but I think you can create a module/bundle in OSGi by using one class but of course you’ll need an interface also since without an interface there can not be a module/bundle.

• 

  Adam Warski September 2nd, 2011 at 14:50

  Sure

  As for the refactoring. If you have a database-reader module, com.company.reader.database package, and insde a DatabaseReader, DatabaseConnector, DatabaseReaderHelper etc classes, refactoring “database” to “db” would involve:
  * changing the module name (optionally: the module indentifier in the bundle definition)
  * changing the package name
  * changing the class name
  It’s quite easy to miss one spot and be left with a db-reader module, com.company.reader.database package and DBReader, DatabaseReaderHelper classes.

  Of course you can create an OSGi bundle/Maven module with a single class, but that’s highly impractical. Imagine defining a pom.xml for every one! That would be a PITA ;). So modularity using OSGi/Maven is naturally limited by practical reasons.

  Adam

• 

  candide September 2nd, 2011 at 15:10

  Yes I see the problem. I think it is related with the lack of support of IDEs/Tools since modularity efforts came a bit lately…

  I should have written that before to be more specific but… I would rather consider if it is wise to have a module based on only one class (in terms of design) rather than impracticality of doing that with available tools…

  I totally understand the pain of selecting and using tools and their shortcomings however I’m really focused at how to break dependencies and I think at that point OSGi specification (I don’t have much experience about available tools) is quite good IMHO.

  Finally it looks like there is a big divergence in Java community for bringing (natural) modularity to Java hence I guess we will have some pain for some time…

• 

  Adam Warski September 2nd, 2011 at 15:18

  Thanks for the link, interesting. I especially like the arguments against the “import” statement.
  One thing in Newspeak is missing though, namely auto-wiring of dependencies.
  It’s a very nice feature or e.g. Guice that I only need to say “XImpl is the implementation that should be used for classes which require X”, without the need to pass the argument explicitly to each use-site.

  Adam

• 

  Adam Warski September 2nd, 2011 at 15:25

  I would rather consider if it is wise to have a module based on only one class

  Sure, that’s where the “module sizes” come to play: you can keep the class as a DI-bean (Spring bean, CDI bean, Guice bean, whatever), or factor is out as a module. Or even better, we could maybe have one mechanism for both! :)

  Adam

• 

  Tomasz Nazar February 22nd, 2012 at 18:44

  “Every” other major lang besides Java supports multiple inheritance or dynamic modules (mixins) that can be added to objects runtime… no big deal.. ;) Ruby, Python, Javascript

  Sorry Java folks :>

  One should use at least AOP for mixing separate concerns into a class/object in Java..
  No pb with AspectJ or JbossAOP, or whatever aop came to Java in this area within last 6 years..

  There is really no way you can modularize code well without having possibility to split a class (code) and then merge it runtime/statically being an object..

• 

  Adam Warski February 22nd, 2012 at 22:31

  AOP is good for cross-cutting concernes. I don’t think anybody uses it for mixins.

  Speaking of mixins, how do they solve the above mentioned problems? In fact the Cake Pattern uses mixins extensively (it’s based on some properties of traits), and still it’s very far from perfect.

  Adam

• 

  Tomasz Nazar February 24th, 2012 at 11:31

  Looks like I assumed some context of my conclusions, and mistaken modularity you’re talking about..

  I thought you’re writing on primary focus of OO: modularity of classes (encapsulation, DRY, small fns, little classes)..

  .. and in fact you’re speaking on packages, modules.. which is .. ehmm.. secondary.

  So excuse my noise here..
  We could talk about OO though :-)

• 

  Adam Warski February 24th, 2012 at 21:19

  DRY – yes, but in another sense (name repetition).
  Encapsulation – yes, but on a higher level (hiding code in one module from another). But is it a higher level? The mechanism is the same, but we don’t hide code in a class, we hide whole classes.
  Litte classes -> little modules?

  I guess modularity in the sense I meant isn’t secondary at all. Both are important in fact.

  Adam