Modularize
From APIDesign
| (One intermediate revision not shown.) | |||
| Line 7: | Line 7: | ||
== The [[Modular Java SE]] Case == | == 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 [[Module system|common ground]] for all [[Java]] [[environment]]s. 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. {{JDK|java/lang|Object}}, {{JDK|java/lang|String}}, {{JDK|java/lang|StringBuilder}}, {{JDK|java/lang|Exception}}, {{JDK|java/lang|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 == | == The Server Side == | ||
Current revision
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.
Follow
