CVS update of julia/src/org/objectweb/fractal/julia (overview.html)

[Lionel Seinturier <seintur@xxxxxxxxxxxxxxxxxxxxxxxxx>]

    Date: Monday, October 30, 2006 @ 15:20:03
  Author: seintur
    Path: /cvsroot/fractal/julia/src/org/objectweb/fractal/julia

Modified: overview.html

Typo and href links.


---------------+
 overview.html |   16 +++++++++-------
 1 files changed, 9 insertions(+), 7 deletions(-)


Index: julia/src/org/objectweb/fractal/julia/overview.html
diff -u julia/src/org/objectweb/fractal/julia/overview.html:1.2 
julia/src/org/objectweb/fractal/julia/overview.html:1.3
--- julia/src/org/objectweb/fractal/julia/overview.html:1.2     Thu Jun 10 
10:49:57 2004
+++ julia/src/org/objectweb/fractal/julia/overview.html Mon Oct 30 15:20:03 
2006
@@ -354,12 +354,13 @@
 inheritance is not available.
 
 <p>Another solution to this problem would be to use an Aspect Oriented
-Programming (AOP) tool or language, such as Aspect/J, since the goal of these
-tools and languages is to solve the "crosscutting" problems. Aspect/J, for
+Programming (AOP) tool or language, such as
+<a href="http://www.eclipse.org/aspectj/";>AspectJ</a>, since the goal of 
these
+tools and languages is to solve the "crosscutting" problems. AspectJ, for
 example, could effectively be used to solve the above problem: three aspect
 classes are sufficient to implement the three concerns, without any code
-duplication. But using Aspect/J would introduce a new problem, due to the 
fact
-that, in Aspect/J, aspects must be applied at compile time, and that this
+duplication. But using AspectJ would introduce a new problem, due to the fact
+that, in AspectJ, aspects must be applied at compile time, and that this
 process requires the source code of the "base" classes. It would then be
 impossible to distribute Julia in compiled form, in a jar file, because then 
the
 users would not be able to apply new aspects to the existing Julia classes 
(in
@@ -367,14 +368,15 @@
 
 <p>What is needed to really solve our modularity and extensiblity problem is
 therefore a kind of AOP tool or language that can be used at load time or at
-runtime, without needing the source code of the base classes, such as JAC 
(Java
+runtime, without needing the source code of the base classes, such as
+<a href="http://jac.objectweb.org";>JAC</a> (Java
 Aspect Components). For performance reasons the current Julia version does 
not
 use JAC or other similar systems: it uses instead some kind of <i>mixin</i>
 classes. A mixin class is a class whose super class is specified in an 
abstract
 way, by specifying the minimum set of fields and methods it should have. A
 mixin class can therefore be <i>applied</i> (i.e. override and add methods) 
to
 any super class that defines at least these fields and methods. This property
-solves the above combinatory problem. The Aspect/J problem is solved by the 
fact
+solves the above combinatory problem. The AspectJ problem is solved by the 
fact
 that the mixin classes used in Julia can be applied at runtime (unlike in 
most
 mixin based inheritance languages, where mixed classes are declared at 
compile
 time).
@@ -672,7 +674,7 @@
 </blockquote>
 
 Note that, thanks to this (elementary) automatic weaving, which is very 
similar
-to what can be found in Aspect/J or in Composition Filters, several aspects 
can
+to what can be found in AspectJ or in Composition Filters, several aspects 
can
 be managed by a single interceptor object: there is no need, and there are
 <i>no</i> chains of interceptor objects, each object corresponding to an 
aspect
 (if one really wants interceptor chains, this can be done by implementing a 
new