Porting Grappa to MixJuice

Expanding Source

Expanding the attached mjGrappa.jar with jar command results a directory named mjGrappa including source under it. $MJGRAPPA denotes the mjGrappa directory.

% jar xvf mjGrappa.jar
% cd mjGrappa
% MJGRAPPA=$PWD

The following is the list of files:

Here shows the module structure of Grappa after ported to MixJuice.

How to Build

Create a file named ant.properties in $MJGRAPPA including the following contents according to your environment.

MJ_EXT=.cmd                     (1)
JAVA_EXT=.exe                   (2)
JAVA_HOME=C:\opt\j2sdk1.4.2     (3)
MJ_HOME=C:\Program Files\mj     (4)

On the environment where ant can be run, do as the following:

% ant

How to Run

Do as the following:

% ant run

If the window like the following picture appears, it runs correctly.

Restriction

The original Grappa enables anti-aliasing, but on porting MixJuice we disabled anti-aliasing. The reason is the following. To enable anti-aliasing it is required to use some constants of java.awt.RenderingHints.Key type like java.awt.RenderingHints.VALUE_ANTIALIAS_ON, and it forces us to care about the problem explained in section The Classes with $ in Their Names of chapter Porting We decided to omit the care and to comment out the part since the problem is not so influential.

Currently, we don't see any other problems.

Is it possible to divide the code into reusable units?

With the current MixJuice, it is hard to create reusable modules, but, in some sense, it is possible to divide into maintainable units. The form of reuse to which MixJuice aims is considered to be likely with mixin, but it seems hard to reuse as mixin from the two reasons below.

The first reason is that, as it is mentioned in MixJuice FAQ, a difference is only applicable to a specific class. For example, assuming that there is a linked list module, it is not possible to apply the module to multiple classes. We hope that a difference could be applied to various classes like a Java interface is implemented to various classes, then a module will become more reusable.

The second reason is that it can not be specified whether a certain module should be applied or not with each instantiation, and the application influences the whole program. (Is it the case of 'I want to use in an application both existing class hierarchy and extended class hierarchy' in the FAQ?) For example, if there is a class DomNode in a module m and we extend it in a module m2, we sometimes need both instances; one applied m2 and one not applied m2.

From the discussion above we conclude that the current difference-based module mechanism of MixJuice is better to ease the extension of existing program or to divide some complex class collaborations into simpler collaborations than to increase productivity reusing the modules. In other words, it is literally good for development based on difference (not reuse).

We classify the forms of reuse below. The mixin we stated here is supposed as equivalent to Self(http://research.sun.com/research/self/)'s mixin (described in The Self Programmer's Reference Manual 3.2.3 Mixins)

Is it possible to divide the code into units easy to maintain?

In this section, we will discuss the maintainability from the view point of easiness to fix bugs and to change for function extension.

About the change at the source code level, it is simply necessary to fix bugs if there are bugs. There is no distinction between MixJuice and Java, in the case. Suppose there be the following program. The implementation of the method Job.execute() is wrong, and the correct behavior is to print "no bug".

module mod {
  define class Job {
    define abstract Job();
    define abstract void execute();
  }
}
module mod.impl extends mod {
  class Job {
    Job(){}
    define void enter() {}
    define void leave() {}
    void execute(){
      enter();
      System.out.println("bug");
      leave();
    }
  }
}
module m.all extends mod {
  class SS {
    void main(String[] args) {
      Job job = new Job();
      job.execute();
    }
  }
}

To fix the bug, it is natural to correct the string "bug" in the original source to "no bug". Therefore, if the correction of original source is possible, it is not preferable to fix bug by adding the new module like the following:

module mod.impl.fix extends mod.impl {
  class Job {
    void execute(){
      enter();
      System.out.println("no bug");
      leave();
    }
  }
}

In the case that the original source can not be changed, the addition of the module mod.impl.fix above fixes the bug. However, the correctness of the implementation of the module mod.impl.fix depends on the fact the original code is available. If the original source is hidden, it is dangerous to replace the method with the module mod.impl.fix. In addition, if the original source is publicly available, it is usually possible to correct the original source.

On the other hand, if the reason to modify the code is not for bug fixes but for extensions or customizes to a specific needs, the difference based module of MixJuice is very useful. There is no reason to preserve the code for a bug, and it is preferable to change the original source code with a bug. In contrast, in case of extensions for a specific needs or so, while modification is required, there is a reason to preserve the original code. Usual way to carry out it is by branching the source code or by conditional compilation, but MixJuice can deal with it as addition of modules. The maintainability of branched versions or sources with many conditional compilation is rather low.

To extend the previous example 1 to print "extension" instead of "bug", modify the module mod.impl at first as the following:

module mod.impl extends mod {
  class Job {
    Job(){}
    define void enter() {}
    define void leave() {}
    define void doIt() { // method extraction
      System.out.println("bug");
    }
    void execute(){
      enter();
      doIt(); // call of the extracted method
      leave();
    }
  }
}

then, add the following module:

module mod.impl.ext extends mod.impl {
  class Job {
    void doIt(){
      System.out.println("extension");
    }
  }
}

In object-oriented programming, by creating subclasses, it is possible to make extension as similar to the module addition. There are, however, advantages gained by MixJuice module addition.

As stated above, MixJuice can extend methods with method addition, but using the function too much makes readability decreased and traceability in debugging harder. In Java, sometimes a process is fragmented in parent and child classes. In the following example, the behavior of the child class when it accept an event can not be understood without reading the methods handle in each of parent and child classes.

  // parent class
  public void handle(Event e) {
    // ...
  }
  // child class
  public void handle(Event e) {
    super(e);
    // ...
  }

In MixJuice, the fragmentation occurs by not only the class inheritances but also module inheritances. It means that the module mechanism increases the maintainability to some degree, but decreases if it is used too much. We conclude that the appropriate use of MixJuice difference-based module enables to manage the extensions, which must be in multiple source branches in Java, in the easily maintainable unit.

In addition, concerning the maintainability, the documentation is an important part. The informations needed for maintenance are the difference-based module provides what kind of difference and the combination of difference-based module results what kind of class. Especially, in the latter case, the documents need be merged as the programs do. In the example below, the semantic interface of the fortune method varies with according to the application of the module mod.ext. Therefore, the way of documentation about interpretation of arguments, exceptions thrown, result, etc. and the system of creating documentation is required.

module mod {
  define class Fortune {
    define Fortune() {}
    /**
     * Tell fortune.
     * @return "happy" or "unhappy"
     */
    define String fortune(int seed) {
       switch (Math.abs(seed % 5)) {
         case 0:
           return "happy";
       }
       return "unhappy";
    }
  }
}
module mod.ext extends mod {
  class Fortune {
    /**
     * Tell fortune.
     * @return "heartbreak" or "lose money" or {@original}
     */
    String fortune(int seed) {
       switch (Math.abs(seed % 5)) {
         case 1:
           return "heartbreak";
         case 2:
           return "lose money";
       }
       return original(seed);
    }
  }
}
module mod.main extends mod {
  class SS {
    void main(String[] str) {
      Fortune f = new Fortune();
      for (int i = -5; i < 6; i++)
        System.out.println(f.fortune(i));
    }
  }
}

Is it possible to divide the code into units easy to hide information?

The unit of information hiding is considered appropriate, basically. However, the inheritance of a module means inheritance of the name space, the terminal module, which inherit many modules, can be suffered with name collision; as in Java importing java.awt.* and java.util.* causes a collision of List. The collision can be avoided by FQN and it is not fatal, but the numbers get the more, the maintainability of program become the lower. In MixJuice, the name spaces are inherited with rather big units, namely modules, there is a possibility that in a huge program the problem of collisions of names will be critical. Thus, to use MixJuice in a huge project it is required to be easy for developers of lower ability than average level to handle without failure and it is required an safety device like limitation.

The unit of information hiding is appropriate, but the unit is module , and the module is also a unit of dividing interfaces with aspect and a unit of extending a program. The module has, as stated above, various roles, and the appropriate division of modules can vary with the roles. For example, we divide Java program into modules with hiding information and at the same time according to the aspects.

package test;

public class Sample {
    public static Sample createSample() {
        return new SampleImpl();
    }
    protected Sample() {
    }

    /*  aspect A */
    public void methodA() {
        methodAut();
    }
    private void methodAut() {
    }

    /*  aspect B */
    public void methodB() {
    }
}

class SampleImpl extends Sample {
    SampleImpl() {
        super();
    }
}

First of all, considering information hiding requires at least three layered modules for public, protected, private (here we ignore the package scope). Then, considering aspects requires to divide specification modules also into three as AandB, A and B. As a consequence, there must be 6 modules; 6 is not from 3+3, it can be 7 or more.

module m { // specification module common to aspect A,B
  define class SampleFactory {
    define SampleFactory() {}
    define abstract Sample createSample();
  }
  define class Sample {
  }
}
module mA extends m { // specification module for aspect A
  class Sample {
    define abstract void methodA();
  }
}
module mB extends m { // specification module for aspect B
  class Sample {
    define abstract void methodB();
  }
}
module m.protect extends mA, mB { // specification module for implementer of subclass of Sample
  class Sample {
    define abstract Sample();
  }
}
module m.sub extends m.protect { // implementation module for SampleImpl
  define class SampleImpl extends Sample {
    define SampleImpl() {
      super();
    }
  }
}
module m.impl extends m.sub { // implementation module for Sample
  class SampleFactory {
    Sample createSample() {
      return new SampleImpl();
    }
  }
  class Sample {
    Sample() {
    }
    define void methodAut() {
    }
    void methodA() {
      methodAut();
    }
    void methodB() {
    }
  }
}

As in the example, using modules for various usages segments modules. Too much segmentation makes program hard to maintain. It is possible to use module as the unit of information hiding, but it is rather realistic to use other methods (using access specifier public etc., for example) for the purpose. It also eases to think about module division with reducing the things to be considered.

Is it possible to divide the code into functional units?

MixJuice is the best at the division into functional units, and the difference-based module offers advantages. At the time of porting Grappa, we added:

• the function to output in dot format to the descendant classes of the Element class by the module att.grappa.dump,
• the GUI function to the class GrappaPanel which had had only function to output graph by the module att.grappa.ui, and
• the constants to the interface GrappaConstants aggregating constants by the modules att.grappa.constants.highlightSettings etc..

Since the task was a porting Grappa from the original Java implementation, it is appropriate to call it separation rather than extension, but anyway, it is possible to extend by functional unit.

In addition, because the units of extension are not classes or interfaces but modules collecting multiple classes and interfaces, the whole extended functions can be easily grasped.

Grappa has some implementations that there are several functions (aspects) in each method. It is a situation commonly seen. There are also many cases that a method interface lie across several aspects. We will give some discussions about such cases.

Is it possible to divide into the unit suitable for separate compilation?

It is possible to employ separate compilation, but it requires advanced build system. For example, we consider the case of 1 module per 1 source file. There is the dependency that parent modules must be compiled before child modules, only the build systems which understands the inheritance relations of module (or source file) can compile in the required order. As a result, for safety, all source files are recompiled. On the other hand, to understand the inheritance relations of modules, it is paradoxically necessary to compile them.

To solve the problem, it needs to prepare an IDE which always grasp the dependency relations between modules and minimize the compilation time. Another solution can be obtained by making a path to grasp the dependency relations before build, like makedepend and make used in compiling X window.

In addition, separating specification modules and implementation modules minimize the necessity of recompilations.

The merit that it is possible to select modules on run time is worth mentioning. For example, you can use it as the following:

• It is possible to use stub implementation modules on the unit test, and to use regular implementation modules after the combined test.
• It is possible to choose depending on the executed environment from implementations; one tuned to speed, or one tuned to memory.

Is it possible to divide into units according to the division of work?

If one can suppose to divide into specification modules and implementation modules, it is possible to divide tasks according to the modules. Otherwise, the recompilations of derived submodules are required each time the implementation is changed, it is difficult to share the work (or to develop simultaneously).

In usual application development is carried out in two orthogonal axes.

Creating base modules from the implementations of architecture side and creating submodules for each application functions seems to make the division of application development smooth; the division according to the functional units of the application. For example, to create DataAccessObject for accessing a database, the following code make the partition of development easy:

module dao {
  define class DAO {
    define void open() {
      //...
    }
    define java.sql.Connection getConnection() {
      // ...
      return null;
    }
    define void commit() {
      //...
    }
    define void rollback() {
      //...
    }
    define void close() {
      //...
    }
  }
}
module dao.addUser extends dao {
  class DAO {
    define void addUser(java.util.Map userData) {
      //...
    }
  }
}
module dao.buy extends dao {
  class DAO {
    define void buy(int userId, int productId, int amount) {
      //...
    }
  }
}

In this example, the module dao should be developed first as the application architecture, then each person responsible to an application function implements the function as the submodules; dao.addUser or dao.buy. As we seen, the difference-based module of MixJuice adapt to the typical development style and make it possible to develop applications in natural pattern.