•J2SE cannot be used (see the gray box in Figure 7.1). There could be several practical
situations that prevent the use of J2SE including the use of Java 1.x legacy code that
would be too costly to reengineer (maybe because ill-documented or badly designed), the
need of compatibility with older tools or libraries, the costs of acquiring new licenses,
• Applets cannot be used (note that this constraint regards the client application, not the
deployment infrastructure, so it cannot be represented in Figure 7.1).
•In our deployment circuit, we need to provide two services: automatic updates and a spe-
cial version of the incremental updates service (line L1 in Figure 7.1).
We have the following available choices:
•Using JRE 1.x to develop from scratch a deployment solution that will work in our sce-
nario (point A in Figure 7.1). Given the impossibility to use applets, we don't consider
the JDK 1.0.x option.
• Choosing a third-party deployment solution—customizing it to fit our needs (point C in
• Employing a skilled workforce (point D)—although possible in theory, is quite inappro-
priate in this case.
For an introduction to the diagrams such as Figure 7.1, see the discussion of Figures
4.1 and 4.3 in Chapter 4.
Of the three possible deployment means for implementing our deployment circuit (points A,C
and D in Figure 7.1), we chose the Java 1.x solution. It requires some additional ad-hoc code
(the arrow W in Figure 7.1) in order to provide the desired deployment services. The final
deployment circuit (that is, JRE 1.x plus some specialized code) is represented in Figure 7.1 by
the point B (that lies on line L1). This choice was motivated by the simplicity of the needed
deployment services, that justifies the use of a potentially more expensive development effort
when compared with the other available options. In fact, customizing a complex third-party
deployment tool would require the prior study of its sophisticated developer APIs together with
the license fee costs and may become more time-consuming than developing the deployment
services from scratch using a more primitive but well-known starting base. In a different situa-
tion, when the needed deployment services are more complex, this choice (a simpler deploy-
ment means) could become too expensive to be adopted.