Modularize

From APIDesign

Jump to: navigation, search

There are multiple correct ways to modularize your applications. How do you select the right one? This article provides you the best guidance you can get.

Contents

No Silver Bullet

TBD: Andzrej's example.

The Modular Java SE Case

The fact that Java's JDK is bloated and needs to be striped down to be competitive with other languages and frameworks is long time well known. The Jigsaw project (and its predecessors) has been created years ago to address that. It's primary motto is modularize the JDK and as could be seen during keynote of JavaOne2012, there is some progress in this respect - a small, java.base module with few additional ones supporting JavaFX was executed (almost) successfully on the keynote stage. Clearly the modularization pays off, one can bring the power of Java to new, limited devices.

Is the current Jigsaw modularization the right one? It certainly is from the point of view of Java mobility edition. The same code can now run in mobile devices as well as on desktop. The java.base module becomes the common ground for all Java environments. However for some usages (like fitting java into 72KB of memory), it is still too bloated?

Why? Because the Jigsaw guys naturally choose the size of java.base to be the smallest for their own needs. What is the smallest need of a person working on Jigsaw? Well, to execute their product. Thus java.base contains support for HTTPS, disk access, various utilities. Clearly a modularization driven by a need.

But I have a different need! I want the smallest possible module to be chosen! What would be its size? Minimal. Just classes that the JavaC is directly aware of when generating bytecode. E.g. Object, String, StringBuilder, Exception, Iterable and few others. That would finally turn Java into flexible and portable framework.

The only necessary precondition is to agree with such need then the right modularization naturally shows up...

The Server Side

TBD: Do you want 14?

Driven by Need

The right granularity and even separation during architecting modular systems is driven by one's need. Primarily by the existing need, secondary by a future need that has to be estimated by envisioning the future evolution of the system.

Personal tools
buy