Adrian,
In my current project, there is a need to
catch typecasting operation but unfortunately current AspectJ doesn't
support it yet. I did some research on this issue and found a research paper on
the same topic (see attached pdf file). I hope it helps.
Thanks
Frank
-----Original Message-----
From: Ron Bodkin
[mailto:rbodkin@xxxxxxxxxxxxxx]
Sent: Tuesday, December 09, 2003
11:49 AM
To: aspectj-users@xxxxxxxxxxx
Cc: AspectJ Dev List
Subject: Re: [aspectj-users] Plans
for the next release of AspectJ...
This sounds like a good
plan. Here are some thoughts:
1. I'd like to see enh
#42743 addressed along with any change to declare soft (as in). It's a P2 for
me: I find the code the results from implementing an error handling policy that
softs many types of exceptions to be awful, because there no way to prevent AJ
from softening and resoftening it's own SoftExceptions! I would support
changing declare soft so that it ONLY affects checked exceptions; would anyone
object vociferously to that? I see that as a logical combination with
45231. I also added some comments to 45231, to suggest allowing calling a
method to determine what exception to throw, rather than returning a constant
type.
2. I'd also really like
to see 48091 get addressed in this round: lazy instantiation of join points
would be a major performance optimization for aspects for early adoption cases:
including capturing args to a method exec that throws an exception (you only
want to pay the price when an exception is thrown), to tracing (only when
enabled), etc.
3. Related to 41952, I'd
like to see a TypePattern operator -, which is the opposite of +. This will let
you talk about methods defined on a given type without being vulnerable to pull
up refactorings breaking the code, e.g., you write a PCD with a signature like
* MyClass.foo(..) or * MyClass.*(..)). Then someone refactors and makes MyClass
extend Abstract, and pulls foo up to be defined in Abstract. Now your PCD
breaks! Now, in a dynamic context the better alternative might be to use
something like this(MyClass) && execution(* foo(..)), but this won't
help in withincode nor for static methods.
If you could write *
MyClass-.foo(..) or * MyClass-.*(..) your pointcut would be more robust; the
refactoring wouldn't cause problems. It would also avoid surprises when you
override a method and suddenly it IS captured by the PCD.
The bigger question is
whether this MyClass- behavior should be a default (maybe the current behavior
could be defined as exactly(MyClass).foo or MyClass defines foo or ???).
Ron
Ron Bodkin
Chief Technology
Officer
New Aspects of Security
m: (415) 509-2895
------------Original
Message------------
From: Adrian Colyer
<adrian_colyer@xxxxxxxxxx>
To:
aspectj-users@xxxxxxxxxxx
Cc:
aspectj-dev@xxxxxxxxxxx
Date: Tue, Dec-9-2003
2:26 AM
Subject: [aspectj-users]
Plans for the next release of AspectJ...
This email is to share with you our
current plans for the next release
of AspectJ (probably numbered v1.2),
in order to get your feedback and
input on our direction, and so that
you know what to expect over the
next few months.
A critical factor in our planning is
the availability of Tiger (J2SE
1.5) support on the Eclipse
platform. The Eclipse 3.0 plan
(http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html)
indicates that 3.0 will include
early support for Tiger. Eclipse 3.0
is planned for release in June 2004.
We plan therefore to do one more
major release of AspectJ before
beginning work on Tiger support. This
release (v1.2) will lay the
groundwork for a follow-on that delivers
Tiger support (generics, metadata,
and more) as quickly as possible
thereafter.
We think AspectJ 1.2 should include
official support for weaving at
class-load time, quality and
performance improvements aimed at users
developing large, complex software
systems, and better support for IDE
integration (such as AJDT). We will
defer most language changes to the
next (J2SE 1.5) release.
Listed below are the main items that
we believe we can or can't do for
1.2. Many of the IDE related
improvements will be most visible in AJDT
(for a list of features slated for
the next AJDT release see the
"plans" link from the AJDT
homepage: http://www.eclipse.org/ajdt). If
your favourite feature is not
represented, and you believe our
priorities should change then please
let us know. This is also a good
time for new contributors to step up
and implement fixes or features,
always a good way to make sure the
things you care about get
done ;). Contributing now will
position new developers for a role in
the J2SE 1.5 related release, which
promises to be a major milestone
in the evolution of AspectJ. If
you're thinking of contributing please
contact myself or one of the AspectJ
team directly so that we can talk.
Strong candidates for the 1.2
release:
================================
Feature highlights:
---------------------------
* weaving class loader support
* improve performance and memory
usage for compile/weave and runtime
* provide documentation and samples
for using AspectJ with popular J2EE servers
* allow the specification of input
directories (not just jars) for binary weaving
* enhancements to IDE support for
incremental structure model
For a full list see:
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/developerPlans.html
A number of bugs have also been
ear-marked for fixing in the 1.2 release. These are listed at the above
address.
Potential candidates for the 1.2
release:
==================================
Feature highlights:
---------------------------
* pertype aspect instantiation model
* class attributes in type patterns
* support for context information in
declare error/warning messages
* user specifiable exception in
declare soft
* serial version uid support
For a full list see:
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/developerPlans.html
A number of bugs have also been
ear-marked for potential fixing in the 1.2 release. These are listed at the
above address.
Thanks and stay in touch -
The AspectJ Team.