Troubleshooting Java code: Eliminating coupling associations between packages

One of the recurring problems in test-priority programming (Test-first programming) is that it seems impossible to automate many parts of a program. Especially when the program is to a large extent to take advantage of external resources and libraries, it seems difficult to test it, because there is no good way to simulate the program and the external resources of the connection.

However, although it is difficult to test such a program with only Java code, there is one type of programming (with development tools) that solves the problem-component-based programming.

Component-based programming and Java language

What do I mean by component based programming? I just mean that each unit of the program is distributed, not a run-time "component" like JavaBeans or similar technology.

Conceptually, the units of these distributions are roughly similar to Java packages. However, packages in the Java language are very restrictive because they are coupled to each other. The classes in each package are hard connected to the packages they import (because the classes must explicitly reference the imported packages).

Because these packages are mutually coupled, it is difficult to unify references to other packages that provide the same functionality instead of those in the program.

Similarly, individually developed teams may occasionally use duplicate package names, which can cause problems when they try to use each other's packages. To ensure the uniqueness of the package name, Sun strongly advocates that each development team use this Convention: the Internet address in reverse order is prefixed to all packages developed by the team. Developers usually follow this convention, but this is not always the case.

However, even if the package naming convention is strictly adhered to, there are other reasons why the programmer wants to disassociate the components. One reason is that this can be more effective in testing these components--when it comes to component-based programming tools (Jiazzi component systems), this is explained.

Jiazzi: Component systems for the Java language

Jiazzi is a promising, component-based programming system in the Java language that is fully compatible with the JVM and completely relieves coupling between components, a project developed by the University of Utah's computer science department. This system allows programmers to stack components and connect them on top of existing Java code. Without the need to modify the Java language or JVM.

Description of the developer

This is described by Jiazzi developers:

...... is a system that supports the construction of large binary components written in Java [added support for large binary components written in Java]. The Jiazzi component can be viewed as a generalization of Java packages, with the addition of external links and independent compilation support to these Java packages. Jiazzi components are useful because they are constructed from standard Java source code. Jiazzi requires no extensions to the Java language or special conventions for writing Java source code, which will be written inside the component. Our components are expressive, because Jiazzi supports looping component links and mixin, and uses loop component links and mixin in open class schemas that support adding modules with new features to existing classes.

The current Jiazzi implementation is integrated into the Java Platform with Linker (linker, for operational components) and stub generators (enabling Jiazzi to work with the regular Java source compiler). Components in Jiazzi can include, import, and export Java classes, and can use the Java Platform for inherited language support across component boundaries. In addition to being expressive, these components are robust-you can type the implementation and links of the components separately.

Observe decoupling of components

Let's look at a short example of a Java package view to see how Jiazzi can decouple the components, and this example uses a GUI library package. We will call the toolkit package. To refer to all the classes in the package, an import statement is placed at the beginning of the source file in our package:

package view;
import toolkit.*;
...