Comments on: Chapter 2 – Module Defined

By: Dinkar Gupta

Dinkar Gupta — Mon, 24 May 2010 11:03:24 +0000

Wanted to correct one thing… The definition does include interfaces “… provides a concise interface to consumers”. what I meant by missing is, some explicit mention of the provided interfaces.. just like you have provided some for other characteristics of the module (in 2.1.1 – 2.1.6)

By: Dinkar Gupta

Dinkar Gupta — Mon, 24 May 2010 10:57:56 +0000

I have only gone this far in reading the chapters but one thing which seems to be missing is the Module interfaces. In my view, a module’s definition is incomplete without talking about it’s interfaces (what does it offer?). You have already mentioned about dependencies – which is the “required interface” part of the module definition. I think it will be a good idea to touch upon the “provided interface” aspect of modules in the beginning to set the context for later chapters. The context of model (runtime or development) on the nature of these interfaces and the design (physical as well as logical) is a very important aspect of modulalization. Some patterns related to design of interface contracts, keeping runtime modularity, reuse and maintainence in mind, is something which will be of immense value.

By: Glyn Normington

Glyn Normington — Fri, 05 Feb 2010 11:51:56 +0000

“A module is a JAR file” isn’t true. Maybe this is simply hyperbole. “A JAR file is a module” is closer to the truth, but even then there are caveats if a JAR file is to meet the criteria in this chapter. “A JAR file is the best basis for a module that is readily available in Java” is the truth, but is hardly worth saying.

By: Craig Walls

Craig Walls — Fri, 15 Jan 2010 19:06:05 +0000

Figure 1 is awesome. It sums up pictorially what I’ve been trying to describe (not so elegantly) for a few years. Beautiful.