[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-dev] Themes for AspectJ 1.2
|
All,
I agree with Ron on the issue of outputting to source (like in the 1.0
series) as it is very helpful for build integration. Also, I have used it
as a means to verify that I have properly created my aspects.
Thanks,
Ron DiFrango
-----Original Message-----
From: Ron Bodkin [mailto:rbodkin@xxxxxxxxxxxxxx]
Sent: Wednesday, October 01, 2003 5:57 PM
To: aspectj-dev@xxxxxxxxxxx
Subject: Re: [aspectj-dev] Themes for AspectJ 1.2
I would add ajdoc into the proposed usability category. In fact, IDE support
really belongs in this bigger category.
Another important item for usability is "eating our own dog food"; using
AspectJ more in developing AspectJ. And using AJDT in developing AJDT. I
would suggest starting with using AJDT to develop AJDT (i.e., using an
AspectJ nature even with limited aspects, and adding aspects over time).
This will indirectly benefit all the other themes too.
Another feature request that probably goes under usability is to output
woven source instead of bytecode. Decompilers like jad do a bad job with
AspectJ-woven sources, and generating sources is occasionally important for
build integration (e.g., with Clover?) and for users to troubleshoot
problems. I don't think this one is a priority, but it ought to be "on the
table."
I don't think supporting researchers or VARs should be emphases for 1.2; I
think performance, scalability, and usability for projects using AspectJ in
production should be.
Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895
> ------------Original Message-------------
> From: Wes Isberg <wes@xxxxxxxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Wed, Oct-1-2003 12:35 PM
> Subject: Re: [aspectj-dev] Themes for AspectJ 1.2
>
> Other possible themes, some with new features, others adopting known
> feature requests...
>
> * Usability
> - speed/performance here
> - better error messages
> - docs/samples here
> - simplified language: enforce subset of most-used,
> most-understood features - training wheels?
>
> * Reusability
> - fix limitations and holes in developing
> and maintaining reusable aspects
>
> * Technology toolkit
>
> - for static analysis
> - permit developers to plug in components or define
> staticly-executable advice to better integrate
> static and dynamic verification. See related AOSD 2003:
> "A case for staticly-executable advice: checking the
> law of Demeter with AspectJ"
>
> - for VAR's
> - many tools could be implemented using an embedded
> weaver, some AspectJ code, and perhaps some
> configuration:
> - the JBoss framework
> - architectural constraint checking
> - automated test tools
> We could make this easier through another component
> like AJDE for such integrations.
>
> - integration with other AOP tools and toolkits
> - running JBoss interceptors
> - the concern manipulation framework
>
> - more modular design
> - is it possible to move towards something like JMangler's
> approach, to make it easier to experiment with new
> language features?
>
> * Increasing capacity
> (more about management, but, hey, it involves 1.2)
>
> - Right now (IDE, compiler, weaver) resolves mainly to
> (Mik, Jim, Erik). It would be nice to free them
> entirely from primary bug-fixing duties. We could
> enlist a team for the 1.1.X branch and divide the work
> accordingly. The 1.1.X team would work with the 1.2
> team to integrate 1.1.X fixes into 1.2, and would thus
> train up for maintaining 1.2. This avoids the 1.2
> team being pulled back to fix pressing 1.1.X bugs
> and important bugs going unfixed for months.
> (However, the set of bugs that can be fixed without major
> changes might be small.)
>
> These raise the question of what we want most from 1.2:
>
> - to meet the current needs of current users
>
> - to increase the number and skill of AspectJ users
>
> - to answer challenges from alternatives
>
> - standardization, de facto or de jure
>
> - to reach the enterprise market
>
> - to reach more researchers
>
> - to advance the art in AOP
>
> Depending on our focus, we attract different kinds of interest and
> contributors. Some features, e.g., distributed aspects and enhanced
> IDE support, nicely serve many goals.
>
> Wes
>
> Adrian Colyer wrote:
>
> > Now that AspectJ 1.1.1 is out, it's time to turn our attention to
> > 1.2.
> > This post is to start a discussion about possible themes and priorities
> > for the 1.2 release. The eventual plan will be influenced by AspectJ's
> > users, it's developers, and of course which items contributors will sign
> > up to implement - so anything we discuss here should not be treated as a
> > plan commitment at this stage. I'm including all project tasks, not just
> > those that might involve writing code.
> >
> > With that said, here are some candidate themes to start the
> > discussion
> > (not an ordered list):
> >
> > * AspectJ for the Enterprise
> >
> > This theme could include adding (and developing) material for the
> > website
> > / docs / ... explaining how to use AspectJ with various app servers and
> > J2EE technologies. A classloader would come under this category too, and
> > perhaps even a set of samples or an aspect library for working with
> > AspectJ in J2EE.
> >
> > * Preparation for Java 1.5
> >
> > Including consideration of the impact of generics and metadata on
> > the
> > language.
> >
> > * Performance and scalability
> >
> > Memory usage (across AspectJ and AJDT), compile time, weave time,
> > runtime
> > performance. This theme might for example build a benchmark suite and
then
> > use it to optimise the compiler and its output. Supporting pertype could
> > fall into this category - as it's needed for some common logging idioms,
> > as could looking into the possibility of creating thisJoinPoint objects
> > lazily.
> >
> > * Enhanced IDE support
> >
> > Work in the ajde components (and possibly below) to allow deeper IDE
> > integration (e.g. to support eager outline views, code formatting,
> > structure model operations etc.). JSR 45 support. AJDT needs this...
> >
> > * Clean-up : working through P3's etc. that have built up during
> > release
> > cycle
> >
> > We have a reasonable list now that we're going to have to work
> > through.
> > This task will also include things like fixing up the failing BCWeaver
> > tests
> >
> > * Miscellaneous (these things don't fit neatly in any of the above
> > yet)
> >
> > There are many items carried over from 1.1 planning for example,
> > that we
> > should consider (some may fit into the above themes). I'll dig these out
> > and post separately. One item I would like to consider is getting
context
> > information into declare warning / error messages (we had a prototype
> > implementation here in Hursley a while back but never got to discussing
> > the rights and wrongs on the list as there were other priorities at the
> > time). Wes has begun work on some general purpose samples and we should
> > continue that.... there's the possibility of a general purpose aspect
> > library in time.
> >
> > I'd like to begin our planning by focusing on what the right themes
> > are to
> > go after (please cast your votes, and add your own suggestions too) on
the
> > dev list, then we can go to the users list once we have a first pass in
> > place. Then we have to start fleshing out what the individual items we
> > want to attack in each category are, and figuring out who wants to work
on
> > what.
> >
> > -- Adrian
> > Adrian_Colyer@xxxxxxxxxx
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-dev
**************************************************************************
The information transmitted herewith is sensitive information intended only
for use by the individual or entity to which it is addressed. If the reader
of this message is not the intended recipient, you are hereby notified that
any review, retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this information is
strictly prohibited. If you have received this communication in error,
please contact the sender and delete the material from your computer.
