\Ssect{Performance Evaluation}{reqprops}

\johan{This is where we summarize how \aj and \hj failed, not because they suck, but because they miss the important properties we discussed earlier. This is the end of the first part of the paper, so this should really be a mini-summary.}

\johan{
\bookmark
}

\begin{smallenum}
The {\aj} solution has many subtle points, but we want to make a number of observations.
\citem % composition 
\johan{This is supposed to talk about composition, but fails to make that point}
The command line used for {\aj} also determines which {\tt .java} files we must comprehend in order to understand local behavior. 
Since a method in a class can be advised by any aspect in the system, we must determine the totality of aspects that have been compiled and determine which methods they affect before we are able to understand the effect of calling a method.
\citem  % powerful
{\aj} has been designed for convenience and power. 
Pointcuts are integrated into Java in a very intuitive fashion, interacting with late binding to allow reuse of aspects in several situations.
Unfortunately, as a modularity construct, this is unsatisfactory, as it becomes impossible to keep the various uses of the aspect separate from each other.
\citem  
The genericity mechanism for advice has similar design choices, promoting convenience for programming in the small over predictable behavior in edge cases.
\citem  % name leakage
There are no encapsulation boundaries for advice, allowing the programmer to decide how generic or how convenient to write aspects.
Of course the Java concepts of private and public can be used for advice, but there are no provisions for controlling the visibility of the methods introduced by \type{Adapt} so that they are visible to the abstract aspects but not other classes in the system.
\citem  % invasiveness
Lastly, care must be taken so that multiple uses of an aspect do not become intermixed. 
It seems likely that an aspect's deferred behavior (expressed as methods on the aspect's interfaces) will be implemented by the concrete aspect by downcasting the interface types to the known implementing classes.
This will be necessary if we wish to gain access to behavior not exposed by the aspect's interface.
It is probable that such access will be needed in order to implement the methods required by the interface.
\end{smallenum}

These points may seem to be overly negative, but should rather be read as confirmation that {\aj} is clearly (and convincingly) designed to be a convenient tool for programming in the small rather than as an advanced module system.

\johan{\hj summary is a bit short}

{\hj}, on the other hand, promotes modular reasoning and control over direct convenience.
While highly reusable, the solution for {\hj} is not intuitive: for example it requires splitting of advice to \java{associate} into before and after advice, and requires significant manual relabeling of methods in order to simulate around advice. 
For all this, it still faces possible casting errors when providing advice access to a method call's arguments.


%% Nov 15: Not sure this meshes with current paper: Do we claim \hj is a module system?
Like {\aj} these points are not criticisms of {\hj}'s design, but rather evidence that modularity alone is not sufficient to  elegantly provide reusable  solutions to complex programming problems.

\johan{Something about how encapsulation (lack thereof) would be easy to solve, so not a huge issue. Flexibility and genericity is more problematic.} 

This concludes the first part of the paper.  In the next section, we
describe the design principles behind {\ACs}, and in \Ref{Section}{ac}
bring the {\AC} solution to the challenge problem.