HyperJ
Make extensions to existing Java programs, integrate Java programs, and remodularize Java programs without having to modify, or even have, source code.
Date Posted: January 7, 2000
|
|
 |
|
|
|
Yes. HyperJ uses class files and does not need source files to work. Of course, you need some understanding of the program, such as interfaces and method signatures, but this can be obtained from documentation or from class file dumps produced by javap. | | |
|
Yes. The class files produced by HyperJ are standard Java class files that can be used just as class files produced by a Java compiler, including use as input to HyperJ. | | |
|
Yes. The class files produced by HyperJ are standard Java class files that can be used just as class files produced by a Java compiler. To use them, you need to know some of the details, such as interfaces and method signatures. HyperJ does not produce source files, but you can obtain this information in a number of ways:
- by running javap on the composed class files
- by examining the "unparse files" produced by HyperJ in verbose mode; these are not Java source files, but they do contain most declarative information.
- through your understanding of the composition process.
| | |
|
Not yet. In principle this can be done -- library classes, except perhaps those that the Java system treats as special, such as Object, are just regular classes with standard class files -- but there are some implementation kinks we have not yet worked out. This capability is planned for the next release. | | |
|
HyperJ works at the granularity of whole members and does not support pulling apart of code within method bodies. This leaves two choices:
- You can exclude the method entirely from compositions, perhaps by assigning it to a "None" concern. Instead, you provide your own methods to do the necessary processing, separately, for each concern of interest, and use HyperJ to compose these as desired. If you are very lucky, the needed per-concern methods will already exist in the program, with the tangled method merely calling them. This approach is illustrated in the example in Chapter 5 of the HyperJ manual.
- If you have the source code, you can modify it by hand to split the method.
| | |
|
The first release is a file-driven, batch version that has a number of limitations, noted in the manual. Some key features planned for future releases include: an interactive GUI, support for composition of Java library classes, and more convenient ways to specify a number of common compositions.
Updates to HyperJ include the following:
- simplified control files (allowing one instead of three, and often abbreviated)
- support for different bracketing of the same method for different call sites
- some additional composition relationships
- "unimplemented error" exception to allow easier writing of declaratively complete class fragments
- summary function library
- compatibility with Tengger, which provides support for composition of UML models and generation of Java from UML.
| | |
|
"Separation of concerns" is simply an approach to decomposing software into modules, each of which deals with, and encapsulates, a particular area of interest, called a concern. Examples of concerns are functions, data types or classes, features (such as persistence, print, or concurrency control), variants, and roles. Object-oriented languages permit decomposition by class, but only by class. Unlike classes, other kinds of concerns cannot be encapsulated in single modules; instead, their implementations end up scattered across the class hierarchy. | | |
|
HyperJ provides a powerful composition capability, which can be used to combine separated concerns selectively into an integrated program or component. For example, it can be used to create a version of a system that contains some features, but not others, even if the original system was not written with the features separated. It can be used to extend or adapt a component, even if that component was not written with suitable hooks or open points. To give a concrete example: Suppose a developer needs to produce an XML representation of a complex domain model that spans a large system. Rather than modifying the classes involved in the domain model to add XML streaming methods, the developer can code these methods in a separate package (or packages) and integrate them with the domain model classes using HyperJ. | | |
|
The file hyperj.zip contains the following directories and files:
- bin directory
hyperj.jar: A JAR file containing the HyperJ class files.
- doc directory
hyperj-user-manual.ps: Describes the use of the HyperJ tool.
- demo directory
This directory contains the Java source code and various HyperJ specification files (described in Chapter 4 of the "User Manual") for an example application (elaborated upon in Chapter 5 of the "User Manual").
| |
|
|
|
|
| |
