{"id":650,"date":"2011-10-04T16:14:00","date_gmt":"2011-10-04T16:14:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/java-modularity-approaches-modules-modules-modules.html"},"modified":"2012-10-21T20:32:53","modified_gmt":"2012-10-21T20:32:53","slug":"java-modularity-approaches-modules","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/10\/java-modularity-approaches-modules.html","title":{"rendered":"Java Modularity Approaches – Modules, modules, modules"},"content":{"rendered":"
I think everybody will agree that writing modular applications and modularity in general is a good thing.<\/p>\n

But how does support for modularity look like, both from the Java and Scala languages and various Java\/Scala frameworks? There\u2019s a lot of different approaches! Let\u2019s look at some of them. Below \u201cprotection\u201d means how well modules are separated either at compile-time or run-time.<\/p>\n

Packages<\/strong><\/span><\/p>\n

First of all we\u2019ve got Java (or Scala) packages<\/strong>. The concept is very useful when it comes to organizing the source code. However it doesn\u2019t offer compile-time or run-time (except for the package-protected visibility, which isn\u2019t used too widely) protection, so it\u2019s rather hard to say that packages are any help in modularizing the code. Also, there\u2019s a lot of naming problems and hence conventions: if for example we have two implementations of a data reader, one using a database, the second using the filesystem, should the associated classes go to database and filesystem subpackages, or stay in the same top-level package? Should the class names be prefixed with Database and Filesystem, even if they are inside the dedicated packages?<\/p>\n

Build subprojects<\/strong><\/span><\/p>\n

Secondly, there\u2019s Maven\/SBT modules\/subprojects<\/strong>. They offer compile-time protection, which is a very nice thing: we can now statically make sure that our code only references classes from the explicitly specified dependencies. However, then comes the obvious question: when is a functionality \u201cbig enough\u201d to make it a separate Maven module? Is it ok to have many Maven modules, each containing only several classes (which can be a PITA, having to define a separate pom, directory structure for each), or should they be bigger? What about naming conventions, should the package name correspond to the module name? If so, we\u2019re clearly violating DRY<\/a> here ;)!<\/p>\n

Imagine we decide to put our database and filesystem data readers into separate packages, maven modules and name them appropriately. So we have a DatabaseReader (plus 10 helper classes) in a foo.bar.database package in the myapp-database Maven module. Now a simple refactoring: renaming \u201cdatabase\u201d to \u201cdb\u201d becomes a really complex task, most certainly ending up in using various terms in various places.

<\/div> <\/div><\/p>\n

OSGi<\/strong><\/span><\/p>\n

The next step of the evolution would be OSGi bundles<\/a> (or, equivalently, a module in JBoss Modules<\/a> or in Project Jigsaw<\/a>). One such bundle is typically a product of one (or more) Maven module, but it also offers run-time protection by appropriately scoping class-loaders. All of the problems from Maven modules are inherited \u2026 with the additional need to name the bundle!<\/p>\n

Nested classes\/cake pattern<\/strong><\/span><\/p>\n

Another possibility of scoping your code is using nested classes<\/strong>, or even to go further and use the Cake pattern in Scala<\/a>. Apart from the old problems: what package to use and how to name the module class, we\u2019ve got a couple new ones. Firstly, the whole source code of the module is now in one file. This can mean really long files! However maybe that\u2019s more of an IDE problem: nobody said that a file needs to be edited all at once; the editor could show only one module class\/method (like in the Smalltalk IDE). Cake pattern is also not free of problems<\/a>. And, what about nested modules?<\/p>\n

DI frameworks<\/strong><\/span><\/p>\n

Finally, we\u2019ve got various DI frameworks<\/strong> (like Guice, Spring or CDI), where, if we look from an appropriate perspective, we define small modules (classes) which can depend on other modules (injected by the container). Separating the module interface (java interface) from the module implementation (java class), and only injecting the interface is also very common. But again, the only way to partially statically prevent injecting the implementation we have to resort to creating separate -api and -impl Maven modules.<\/p>\n

In fact, if we take the approach of nested classes, a DI framework may be very well suited for resolving inter-module dependencies and doing all of the wiring for us (which can be very useful if we want to be protected from situations where a module has a new dependency, and each use-site must be now amended).<\/p>\n

Next?<\/strong><\/span><\/p>\n

To sum up, I think that the various approaches to supporting modularity could use some unification. And, unfortunately, this would probably mean totally departing from what we know today from Java\/Scala: a new package system, a new build system, a new runtime system. Unfortunately the outcrop of new programming languages doesn\u2019t offer much in that area.<\/p>\n

Do you think there should be one module system, usable both in the small (single classes) and in the large (sets of classes)? After all, what a DI container<\/strong> does to resolve the dependencies and instantiate classes isn\u2019t so much different from what Maven<\/strong> or an OSGi<\/strong> runtime does when booting!<\/p>\n

Or maybe modules inherently have several types, small ones (class-level) and big ones (maven module\/osgi bundle-level)?<\/p>\n

Lastly, maybe there are some other non-JVM based languages, which solve the modularity problem (still being usable) in a nicer way?<\/p>\n

Reference: <\/i><\/strong>Modules, modules, modules\u2026<\/a> from our JCG partner<\/a> Adam Warski<\/a>.<\/p>\n

Related Articles :<\/i><\/strong><\/div>\n