Java Reference
In-Depth Information
2.6.1
Improving the paint program's modularization
In the current design, one aspect that sticks out is the shape-implementation bundle.
Is there a downside to keeping all shape implementations in a single package and a
single bundle? Perhaps it's better to reverse the question. Is there any advantage to
separating the shape implementations into separate bundles? Imagine use cases
where not all shapes are necessary; for example, small devices may not have enough
resources to support all shape implementations. If you separate the shape implemen-
tations into separate packages and separate bundles, you have more flexibility when it
comes to creating different configurations of the application.
This is a good issue to keep in mind when you're modularizing applications.
Optional components or components with the potential to have multiple alternative
implementations are good candidates to be in separate bundles. Breaking your appli-
cation into multiple bundles gives you more flexibility, because you're limited to
deploying configurations of your application based on the granularity of your defined
bundles. Sounds good, right? You may then wonder why you don't divide your applica-
tions into as many bundles as you can.
You pay a price for the flexibility afforded by dividing an application into multiple
bundles. Lots of bundles mean you have lots of artifacts that are versioning indepen-
dently, creating lots of dependencies and configurations to manage. So it's probably
not a good idea to create a bundle out of each of your project's packages, for exam-
ple. You need to analyze and understand your needs for flexibility when deciding how
best to divide an application. There is no single rule for every situation.
Returning to the paint program, let's assume the ultimate goal is to enable the pos-
sibility for creating different configurations of the application with different sets of
shapes. To accomplish this, you move each shape implementation into its own package
(
org.foo.shape.circle
,
org.foo.shape.square
, and
org.foo.shape.triangle
).
You can now bundle each of these shapes separately. The following metadata captures
the circle bundle:
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.shape.circle
Bundle-Version: 2.0.0
Bundle-Name: Circle Implementation
Import-Package: javax.swing, org.foo.shape; version="2.0.0"
Export-Package: org.foo.shape.circle; version="2.0.0"
The metadata for the square and triangle bundles is nearly identical, except with the
correct shape name substituted where appropriate. The shape-implementation bun-
dles have dependencies on Swing and the public
API
and export their implementa-
tion-specific shape package. These changes also require changes to the program's
metadata implementation bundle; you modify its metadata as follows:
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.foo.paint
Bundle-Version: 2.0.0
Bundle-Name: Simple Paint Program
Import-Package: javax.swing, org.foo.shape; org.foo.shape.circle;
org.foo.shape.square; org.foo.shape.triangle; version="2.0.0"
