Spider Graphics

From Ada to Java

an Experiment in Software Reuse

by Istvan Mohos

This collection of Java programs represents my semester project in Software Reuse at Fairleigh Dickinson University, CSCI683981 taught during the Fall of 1996 by Dr. Gertrude Levine. My original plan was to translate to Java, the Ada programs illustrating the textbook Ada 95 by Michael B. Feldman and Elliot B. Koffman (Addison Wesley Publishing Company, ISBN 0-201-87009-6, see readme.ada95 for details). After completing six chapters I realized that my plan was too ambitious for the time allotted, and I trimmed down the scope of the work, translating only that source code from Professor Feldman's nearly 200 program titles in Ada 95 that implements the "Spider Graphics" package.

With this translation I walk a fine line in reproducing Feldman's blueprint as faithfully as possible, and at the same time trying to structure code in a way that makes sense in Java. Bowing to Java's strong object orientation I constructed Spider Graphics from three separate classes or object types: AppFrame, Room, and Spider. AppFrame implements the window frame for the graphics, with functionality loosely paralleling Feldman's "Screen" package. The functions of Room and Spider should be self-explanatory.

The Java code is styled after FDU's internal CSCI Java Style Guide, which in turn adopts conventions discussed in Sun Microsystem's The Java Language Specification (http://java.sun.com/doc/language_specification/). Given that Java is very case sensitive, the most noticeable stylistic differences between the Ada examples and the Java translations are:

  1. Java keywords are all lowercase
  2. All uppercase names are chosen for Java constants
  3. Java class (type) names begin with an uppercase letter
  4. Java class fields (variable and method names inside a class definition) start with a lowercase letter
  5. Java object and variable names are nouns, method names are verbs

Because the Java version of Spider Graphics consists of only three class definitions, these classes are not partitioned into a separate Java package. (Incidentally, a Java package is a collection of related class definitions, as opposed to Ada, where a package usually defines a single class type.) Instead, the user can just compile them in her "current directory", together with any new application code that instantiates or subclasses these types. Java applications must each define a main() function or method, which is the entry point of execution. Java "applets" in contrast, depend on a network browser or on an "applet viewer" to supply the main() method. Since being dependent on a browser would obscure the control flow and signal a radical departure from Feldman's original Ada structures, the supporting examples included here are all "applications" rather than "applets".

To compile and work with the classes of Spider Graphics, you need a Java (byte code) compiler, available free of charge as part of the Sun Java Development Kit (JDK). (To run Java, you have to use a multitasking OS such as Win95, NT, or UNIX.) To compile, go to your directory which contains the Java source files, and issue the following commands:

    javac AppFrame.java
    javac Spider.java
    javac Room.java

Remember, Java syntax is case sensitive. This includes file names and words typed on the command line. After compiling you can start using Spider Graphics in your own applications. A number of small programs that use Spider Graphics are included here as samples. You should also be able to run the Room application in its built-in "debug" mode by typing:

    java Room

The Java source code of SpiderApp1.java through SpiderApp7.java implements variations on a theme of two spiders controlled by a simple for-loop. These programs demonstrate that simple line drawing commands can produce stunning visual effects and computer-generated "art". Minute changes in the controlling parameters bring about dramatic changes in the output. Regretfully I was unable to exhibit SpiderApp pictures here, due to the large size of GIF files and the relative lack of space on this home page.

Unlike in Ada, the "interface", "prototype" or "specification" of class definitions is implicit in the definitions themselves. This makes it all the more important to include API (Application Programming Interface) documents with Java source code. The API for Spider Graphics, in the form of HTML text, was automatically generated with the javadoc utility from comments in the source code. Javadoc does a good job of cross-referencing related topics with HTML links. However, it expects the API of the core Java packages (java.lang, java.io, java.awt, and so on) to be normally available with the Java installation. The current home page cannot be a repository for a full-fledged Java development system, so until you copy the Spider Graphics API to your Java environment (or better yet, until you download this source code and run javadoc on it), HTML links inside it, to core Java topics, will not be found by the browser. The Spider Graphics API contains:

  • tree.html
  • AllNames.html
  • Room.html
  • AppFrame.html
  • Spider.html
  • The source code consists of:

  • Room.java
  • Spider.java
  • AppFrame.java
  • Draw_Box.java
  • Spiral.java
  • Worm_and_Apple.java
  • ThreeRoomFlat.java
  • SpiderApp1.java
  • SpiderApp2.java
  • SpiderApp3.java
  • SpiderApp4.java
  • SpiderApp5.java
  • SpiderApp6.java
  • SpiderApp7.java
  • Room.java is approximately 30K, Spider.java is 10K, AppFrame.java is 6K. The remaining, sample applications are less than 2K each. An obvious "next step" in further developing Spider Graphics in Java, would be to make each spider a thread of its own (an asynchronous program thread, that is -- no pun intended), and implement spider "behavior" based on feedback from the room or rooms that serve as the spider environment. Feedback could be based on proximity of walls and of other spiders, the previous pixel color of the Point that a spider is moving over, memory of previous headings, and so on.

    Thank you for visiting this page.