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.
|