---------- Forwarded message ----------
Date: Tue, 28 Sep 2004 20:06:45 +0100
From: Adrian Colyer <adrian_colyer@uk.ibm.com>
To: Ganesh Sittampalam <Ganesh.Sittampalam@comlab.ox.ac.uk>
Cc: Andrew Clement <CLEMAS@uk.ibm.com>
Subject: Re: bits and pieces from Thursday's meeting
Hi Ganesh,
It's been a mad couple of weeks since you visited us, so my apologies for
the delay in this reply. I've been travelling and Andy's on vacation
leaving us rather thin on the ground. Attached are the comments from Erik
that I referred to. I'll submit the bug in abc when I get connected again
(I'm on a plane to Boston at the moment) - it would be an honour to submit
the first external bug report :)
Regards, Adrian.
--- from Erik Hilsdale --
My two cents on their docs (please feel free to distribute):
Differences with ajc
* abc takes a different approach to the new keywords
introduced in AspectJ. In ajc the AspectJ-specific
keywords are also allowed to be used as identifiers. In
abc we follow the design of Java in that we clearly
distinguish between identifiers and
keywords. Specifically, in abc the set of new keywords
depends on the context:
This is an interesting design choice. I'm not sure you gain much
over AspectJ apart from clarity. On the other hand, you do gain
some clarity (and, I assume, ease of implementation of the
parser), at the expense of only three keywords to normal Java
programmers.
* ajc allows the parentheses around IOException in
declare soft: (IOException): module();
However, even ajc only allows a type in that position,
and there is no other place in Java where types may be
parenthesised. abc therefore forbids these parentheses.
AspectJ allows parentheses here because we wanted to leave open
the possibility of a type-pattern as a non-terminal in that
location in the grammar. Because I think of declare soft as a
feature still in flux, any difference in the grammar seems pretty
unimportant. However, I would advise against making other design
choices that rely on an exact type in that location.
* ajc allows constructs like if(x instanceof
{int|double|<primitive_type>}), abc does not, for
consistency with pure Java.
Offhand, I don't know if this is a bug in AspectJ, or a specific
design decision for metaprogramming power. I'd probably bet on
bug, to tell the truth. I mean, what do we compile this into?
This has _got_ to generate a bad classfile if we let it
through. Do we _really_ crawl the expression inside of an if
pointcut and fix these things?
* For errors regarding execution joinpoints, abc reports
the entire method body as the error location, whereas
ajc reports the first line of code in the body.
And if the body has no code (i.e., just a RETURN bytecode), I
assume you report the line containing the first brace? Sounds
good, assuming that RETURN bytecode is properly annotated. It
probably is...
<amc> - we fixed the line reporting problem in HEAD a while back,
ajc will now report the first line of the method declaration
rather than the line number of the first bytecode within it :- as
long as the source was compiled by ajc at any rate, if we only
have .class files compiled by a different compiler we can't
improve on the first line of code in the body. </amc>
This affects both declare warning and declare error and
static join point information. Also, abc always reports
staticinitialization joinpoints at the location of the
class, regardless of the presence or absence of static
blocks or initializers.
This sounds like a good idea; I don't know which version is more
useful to users (Mik might want to do a user study or make an option).
This also applies to the
position information of join points reported by
thisJoinPointStaticPart.
* abc does not support compiling the class foo.Bar from a
file Bar.java; you must make sure Bar resides in a
directory that matches the package name, so
foo/Bar.java (or some deeper path such as
a/foo/Bar.java).
Ah, abc doesn't have to support weird invocations that ajc
handles (or handled). Lucky.
* In ajc, use of declare soft can cause exception
checking to be turned off even for code where the
exception has not been softened. We believe this to be
a bug in ajc (72157), and we do not implement this
behaviour.
Ack! Declare soft! Run away, run away!
* In situations where a particular kind of advice is not
supported, abc always reports it as a warning. ajc's
behaviour seems inconsistent - it considers after
advice on handlers as warnings, but around advice on
interface static initializers as errors.
This should be filed as a bug in AspectJ.
* If a name pattern says OuterClass.*, in abc it will
just match all member classes of OuterClass, whereas in
ajc it will also match anonymous classes whose
immediate enclosing class is OuterClass. This is
somewhat related to ajc bug 73050.
...as should this (we have enough info about the anonymous
classes to exclude them, and exclude them we should).
* abc always takes shadowing of class names (an inner
class hiding the definition of a class defined further
out) into account when doing name pattern matching. ajc
only does this for name patterns that are simple
names. This is described in detail in ajc bug 73073.
As Adrian said, this is _definitely_ on purpose in AspectJ and
resulted from some fairly long and drawn out language
discussions about (surprise!) separate compilation.
* abc is a little more liberal than ajc in handling
intertype declarations. If multiple intertype
declarations insert members with the same names and
signature into the same class, then there is no error
if one of the inserting aspects has higher precedence
than all the others. ajc sometimes reports an error if
there is no precedence relationship between any pair of
the inserting aspects.
This should be filed as an AspectJ bug.
* abc always reports an error if a program contains
recursively defined named pointcuts. ajc only reports
an error if such a pointcut is actually used.
This is a good design decision on abc's part that AspectJ should
seriously consider stealing. *smile*
Additional features
abc has a number of features that are not supported by
ajc. Among these are the following:
* abc has optional support for nested comments (things
like /* ... /* ... */ */). To enable this, use the
-nested-comments command-line switch (alternatively,
specify the long form of -nested-comments:on or
-nested-comments:true). You can explicitly disable
nested comments by specifying -nested-comments:off or
-nested-comments:false, if several of these options are
specified, the last one takes effect.
If this kind of option is seen in the wild (i.e., in Jikes,
javac, or command-line eclipse) then AspectJ should probably
follow suit. If not, not.
* Unlike ajc, abc supports around advice on
initialization and preinitialization joinpoints.
Fantastic! I've got to see your generated code for this. I
think we had a vaporware implementation for this with multiple
trampolines and heavy boxing, but didn't implement it because we
couldn't finesse the issues with final field assignment.
* abc allows alternative argument bindings in pointcuts, as in
(args(x,..) || args(..,x)) && if(x==0)
The semantics of such bindings is defined by rewriting
to disjunctive normal form (by distributing atomic
conjuncts leftwards). The first disjunct in the normal
form that succeeds is the binding passed to the advice
body. This is supported with all forms of advice,
including around. ajc does not support alternative
argument bindings.
And unification comes ever, ever closer... *smile*. I'd be
interested to see if the power gained by this is used by real
programmers.
* Contrary to its documentation, ajc insists on the
parentheses in issingleton() (rather than
issingleton). abc allows both.
Another AspectJ bug (I won't say whether it's a doc bug or a
compiler bug *smile*). Though I would argue that allowing both
is probably not the best design decision in the world.
* abc aims to support using declare parents on classes
supplied as bytecode, which is not supported by the
current ajc implementation. However, abc bug 10 means
that this will not currently work for classes being
declared to extend other classes.
This is a good aim.
-erik
-- Adrian
Adrian_Colyer@uk.ibm.com
Ganesh Sittampalam <Ganesh.Sittampalam@comlab.ox.ac.uk>
Sent by: Ganesh Sittampalam <ganesh@earth.li>
13/09/2004 17:54
To
Adrian_Colyer@uk.ibm.com
cc
Subject
bits and pieces from Thursday's meeting
Hi Adrian,
I attach a soft copy of the list of questions we had for you, as
agreed at the meeting. I've updated some of the points to summarise what
we agreed, where I could remember it; in general we should continue the
discussion in detail using bugzilla. The page is a copy of an internal web
page, so the graphics etc may be missing but the content should be there.
We've just released version 0.9.1, which amongst other things has support
for argfiles that I think various people mentioned as being a major
stumbling block in trying abc on existing code. Perhaps you could let
anyone in your team who might be interested in this know.
Could you forward me that message you showed me from Eric (I think) about
our differences list?
We plan to put up a list summarising the optimisations we do as soon as we
have time, so keep an eye on our website for that.
I think you mentioned finding a few bugs; it'd be great if you could enter
them in our bugzilla (which is at
http://abc.comlab.ox.ac.uk/cgi-bin/bugzilla/index.cgi, or follow the link
from the "Support" page).
Cheers,
Ganesh
#### ForDiscussionWithAjcTeam.htm has been deleted (was saved in
repository My Attachments Repository ->) from this note on 15 September
2004 by Adrian Colyer
Received on Tue Sep 28 20:45:47 2004
This archive was generated by hypermail 2.1.8 : Tue Sep 28 2004 - 22:00:02 BST