java 9 : Modular Programming
Modular programming enables one to organize code into independent, cohesive
modules, which can be combined together to achieve the desired functionality. This
allows in creating code that is:
More cohesive because the modules are built with a specific purpose, so the
code that resides there tends to cater to that specific purpose.
Encapsulated because modules can interact with only those APIs that have been
made available by the other modules.
Reliable because the discoverability is based on the modules and not on the
individual types. This means that if a module is not present, then the dependent
module cannot be executed until it is discoverable by the dependent module.
This helps in preventing runtime errors.
Loosely coupled. If you use service interfaces, then the module interface and
the service interface implementation can be loosely coupled.
So, the thought process in designing and organizing the code will now involve
identifying the modules, code, and configuration files, which go into the module and
the packages in which the code is organized within the module. After that, we have
to decide the public APIs of the module, thereby making them available for use by
dependent modules.
Reliable configuration: Developers have long suffered from the brittle, errorprone classpath mechanism for configuring program components. The classpath
cannot express relationships between components, so if a necessary component
is missing, then that will not be discovered until an attempt is made to use it.
The classpath also allows classes in the same package to be loaded from
different components, leading to unpredictable behavior and difficult-todiagnose errors. The proposed specification will allow a component to declare
that it depends upon other components as other components depend upon it.
Strong encapsulation: The access-control mechanism of the Java programming
language and the JVM provides no way for a component to prevent other
components from accessing its internal packages. The proposed specification
will allow a component to declare its packages that are accessible by other
components and those that are not.
The JSR further goes to list the advantages that result from addressing the preceding
issues, as follows:
A scalable platform: The ever-increasing size of the Java SE platform has
made it increasingly difficult to use in small devices, despite the fact that many
such devices are capable of running an SE-class JVM. The compact profiles
introduced in Java SE 8 (JSR 337) help in this regard, but they are not nearly
flexible enough. The proposed specification will allow the Java SE platform and
its implementations to be decomposed into a set of components that can be
assembled by developers into custom configurations that contain only the
functionality actually required by an application.
Greater platform integrity: Casual use of APIs that are internal to Java SE
platform implementations is both a security risk and a maintenance burden. The
strong encapsulation provided by the proposed specification will allow
components that implement the Java SE platform to prevent access to their
internal APIs.
Improved performance: Many ahead-of-time, whole-program optimization
techniques can be more effective when it is known that a class can refer only to
classes in a few other specific components rather than to any class loaded at
runtime. Performance is especially enhanced when the components of an
application can be optimized in conjunction with the components that
implement the Java SE platform.
modules, which can be combined together to achieve the desired functionality. This
allows in creating code that is:
More cohesive because the modules are built with a specific purpose, so the
code that resides there tends to cater to that specific purpose.
Encapsulated because modules can interact with only those APIs that have been
made available by the other modules.
Reliable because the discoverability is based on the modules and not on the
individual types. This means that if a module is not present, then the dependent
module cannot be executed until it is discoverable by the dependent module.
This helps in preventing runtime errors.
Loosely coupled. If you use service interfaces, then the module interface and
the service interface implementation can be loosely coupled.
So, the thought process in designing and organizing the code will now involve
identifying the modules, code, and configuration files, which go into the module and
the packages in which the code is organized within the module. After that, we have
to decide the public APIs of the module, thereby making them available for use by
dependent modules.
Reliable configuration: Developers have long suffered from the brittle, errorprone classpath mechanism for configuring program components. The classpath
cannot express relationships between components, so if a necessary component
is missing, then that will not be discovered until an attempt is made to use it.
The classpath also allows classes in the same package to be loaded from
different components, leading to unpredictable behavior and difficult-todiagnose errors. The proposed specification will allow a component to declare
that it depends upon other components as other components depend upon it.
Strong encapsulation: The access-control mechanism of the Java programming
language and the JVM provides no way for a component to prevent other
components from accessing its internal packages. The proposed specification
will allow a component to declare its packages that are accessible by other
components and those that are not.
The JSR further goes to list the advantages that result from addressing the preceding
issues, as follows:
A scalable platform: The ever-increasing size of the Java SE platform has
made it increasingly difficult to use in small devices, despite the fact that many
such devices are capable of running an SE-class JVM. The compact profiles
introduced in Java SE 8 (JSR 337) help in this regard, but they are not nearly
flexible enough. The proposed specification will allow the Java SE platform and
its implementations to be decomposed into a set of components that can be
assembled by developers into custom configurations that contain only the
functionality actually required by an application.
Greater platform integrity: Casual use of APIs that are internal to Java SE
platform implementations is both a security risk and a maintenance burden. The
strong encapsulation provided by the proposed specification will allow
components that implement the Java SE platform to prevent access to their
internal APIs.
Improved performance: Many ahead-of-time, whole-program optimization
techniques can be more effective when it is known that a class can refer only to
classes in a few other specific components rather than to any class loaded at
runtime. Performance is especially enhanced when the components of an
application can be optimized in conjunction with the components that
implement the Java SE platform.
Comments
Post a Comment