[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.