Re: [aspectj-users] How does the AspectJ team prioritize new features?

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hi Dave,

I like to think votes are a factor in determining what needs doing -
but balanced with a view on what will get the most bang-for-the-buck
given the limited resource.  The team working on it will be expanding
shortly and that should make a big difference.  However, I do find it
annoying that adding votes to a bug doesn't trigger an email but
adding a comment does (can I make bugzilla do that? Honestly I've not
checked).  So new votes can slip by and I'm not aware of the
importance people are placing on a feature until i manually go and
check it.  This happened last week when someone mentioned a problem
they were having, I found the related issue in bugzilla and found it
had picked up more votes than I thought (it was actually the one
related to groovy integration with AspectJ).  If I see comments get
attached to bugs (triggering emails to me), I do get a feel for what
is becoming more important to everyone - and I do see every comment
attached to every AspectJ bug/enhancement.

Obviously I'm not going to say the fact that I'm a
SpringSource(VMware) employee doesn't influence things - but they have
such a diverse set of requirements that I rarely find what they want
doesn't line up with what the community is asking for.  Three examples
right now:

- Spring Roo makes massive use of ITDs.  This drives requirements on
the alternative neater syntax, possibly reviewing name mangling,
optimized compilation of ITD based projects and (i'm about to explore
this) optimizing reloading of AspectJ woven apps into app servers
without requiring them to restart.  AJDT also needs to be great to
support Roo project development.
- Spring Insight makes intense use of load time weaving.  It has all
the requirements you'd expect: incredibly fast matching, fast weaving,
and all whilst using very little memory.
- Spring dmServer is implemented as a large number of AspectJ/Java
projects.  So the behaviour of AJDT and AspectJ incremental
compilation needs to be top notch.


My day-to-day TODO list is as follows.  It is any bug or enhancement
assigned the target of the next release (right now, 1.6.7) - anything
on that list I will at least review once for the forthcoming release
and see if I can get it addressed.  If your issue doesn't have a
target release, I'm afraid it is off my radar - sometimes deliberately
(perhaps it is something I think I'll get to when everything else is
'done', hence it isn't closed), sometimes I've forgotten to attach a
target (oops).  Bring it back to life by making a comment and I'll
review it again.

There is an eclipse planning process that I try to follow but I'm a
bit lax at times unfortunately.  Our planning procedure right now
would be that after each release we review the themes we want to look
at for the next release.  The themes are determined by things that are
long overdue to be done, coupled with features that have been voted on
that we think make sense this time around.  Themes might include
'memory usage' or 'incremental compilation speed'.  But obviously
things also come up mid cycle that have to brought into plan.

The active plan is here:
http://www.eclipse.org/projects/project-plan.php?projectid=tools.aspectj
and I try to mark bugs that I really want to solve in the forthcoming
release with the '[plan]' tag in the bug title.

Let me do a quick review of some of those voted bugs - maybe the
community will find it interesting.

>> Consider extending type pattern matching to support hasmethod(), hasfield()	votes:33
hasmethod(), hasfield() can't be default until some limitations are
addressed.  These limitations are not hit by many people but prevent
me making it default, and it is so easy to just use the flag
-XhasMember to switch it on. I've not seen many complaints about this
lately so it hasn't received much focused effort.

>> Integrate extension to allow groovy compilation	votes:14
A relatively new requirement.  I'm actively thinking about this right
now but it is HARD to do right.  Needs more thinking before keyboard
bashing.  This is likely to happen within the next few months.

>> [tools] AST support for resolving type bindings  votes:11
Unfortunately this issue tends to impact those building on top of AJ
rather than those actively using it for project development - so that
unfortunately drops it down my TODO priorities.  It is incredibly hard
to fix (in a nice way) due to the way the AspectJ extensions have been
made to the underlying compiler.  Unfortunately, right now, I can't
justify taking a month of my time to get this done.

>> Parameter annotation matching to select a subset of arguments	votes:11
I would love to do this! I really would!  I just can't come up with a
syntax/design that doesn't suck.  I encourage everyone to have a read
and let me know their thoughts.  The design must not involve massive
changes to the core of AspectJ, and that is what makes it tricky.

>> Support Load-Time Weaving and HotSwap	votes:5
actively working on this, I just committed a patch to enable it, but
it needs further field testing by willing volunteers.

>> Add ability to associate user object to join point	votes:4
A basic mechanism has been implemented as described in that bug, I
need to decide if it is sufficient for now and I can perhaps close
this.

>> [plan][groovy]Weaving groovy	votes:4
Somewhat hand-in-hand with the other groovy item.  I need to decide on
what it means to weave groovy bytecode.  Some people are already doing
it (eg. Spring Insight) but AspectJ does not police what does or does
not get woven right now in groovy bytecode so they may well
accidentally weave groovy infrastructure unintentionally.

>> Introduction should not unnecessarily change the public interfaces of classes	1
Hope to pick this up as part of my ITD naming review, however I'm not
sure anything will change for this *particular* issue, I will just end
up with a correct set of documentation available saying why it is how
it is.

So there you go, a bit of insight into what is being looked at right
now.  I would encourage everyone to use voting/comments to raise the
importance of issues.

cheers,
Andy

2009/11/19 Dave Whittaker <dave@xxxxxxxxxx>:
> I'm curious about the internal process.  I just did a quick bugzilla search
> and noticed there are 177 open feature requests and only maybe 10 of them
> have any votes.  Let me put out the disclaimer that I realize you guys are
> under no obligation to prioritize things based on the feelings of us
> non-contributing freeloaders, I'm just interested in whether there is a
> formal/informal process of determining which feature has the most merit,
> whether it has anything to do with votes, and I guess in whether others who
> participate on the list actually use the votes to let the developers know
> what they'd like to see done next.
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>