[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [aspectj-dev] AspectJ Custom Attributes
- From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
- Date: Fri, 21 Oct 2005 09:50:42 -0700
- Delivered-to: email@example.com
- Organization: New Aspects of Software
- Thread-index: AcXWU9L3p531rEUBSqetOiQSZB+CCAACr9Jg
It seems to me that if AspectJ moves to annotations instead of custom
attributes, it would be reasonable to do it in a dot release (5.0.2?) after
a careful design. Hopefully ASM will include support for AspectJ 5
attributes given that they are not using the constant pool, hence should
work properly given your proposal Eugene.
For users who want easy support in (other) tools like ASM, they could
recompile their code with the new release to interoperate better. If they
have a binary jar they can just reweave it ;-) So forward migration wouldn't
be too bad.
None of this would obviate the need for backward compatibility: AspectJ
already has to support aspects in 1.1.x and 1.2.x bytecode format with
custom attributes. Adding 1.5.0 into the mix doesn't seem to me to make
matters that much.
Moreover, I think Andy's right to want to defer this until after 5.0, and if
a new format is decided on, it's worth taking some time to make it optimal.
On the other hand, if ASM supports AspectJ attributes, it's also worth
looking to see what other bytecode modification tools are important enough
to justify the effort, possible instability, and code bloat of supporting
yet another format going forward.
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Eugene Kuleshov
Sent: Friday, October 21, 2005 8:26 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] AspectJ Custom Attributes
Andy Clement wrote:
> This point you made is very interesting and hadn't crossed my mind before:
>> Another huge reason is that annotation attributes allow to reuse
>>and benefit from the class constant pool. So, you can share the same
>>string, class and other literals and constants with the rest of the
>>class bytecode. That not only decreases the bytecode size, but also
>>give additional simplicity for static bytecode analysers (including
>>tools like jarjar).
> We made the AspectJ 'reweavable' option the default recently which has
> increased the size of class files we create - this would be a way to
> recover some of that space... however, if we just took what we store
> in attributes at the moment and stuffed it into annotation with a
> 'byte value' in it, we wouldn't get this benefit... so clearly some
> detailed thought needs to go into any potential switchover to
That is absolutely right. There would be no real size and
structural advantages in just using some annotation with byte or
String property, though it still would be more transparent to the 3rd
> And that is really my concern over doing it - the required engineering
> effort given that 1.5 has been under development for what feels like
> forever and we just want to ship the darn thing. At some point we
> have to draw a line and say *thats it, no more goodies in this
That is fair. I absolutely agree that it is very important to
release this version.
However it would make sense to think about some migration strategy
if AspectJ will decide to switch away from the custom attrs (which
look very unlikely).
> To move to annotations properly we need to ensure we
> continue to support reading in old format .class files and we need to
> make sure we can manipulate the annotations correctly without the
> compiler getting a 1.5 dependency (I know this can be done, I just
> think it needs some thought rather than being hacked in) - i think
> those kind of changes would cause us to ship a Milestone5 build next
> rather than ReleaseCandidate1. It would be a shame to rush an
> implementation into 1.5.0 and be stuck with it after that ...
Anyway, I do agree that it will require some time to came with good
attribute-based implementation. That is why I am being pushy in this
By the way, using annotation attributes does _not_ enforce you to
have 1.5 dependency in the compiler neither have Annotation classes
around to read the content of these attributes when working with
bytecode directly. Especially if you would use CLASS they all going to
be ignored by VM.
More over, if you can make an assumption that content of these
annotations is valid (that is very reasonable for AJ own
annotations/custom attributes) you can actually generate these
Annotation classes on the fly from the content of the attributes
(except maybe that you won't see unused optional properties), e.g. to
be used with reflective calls to Java5 introspection API... or use
some custom accessors like I've illustrated in one of my ASM articles
or the one Alex and Jonas implemented in backport175.
aspectj-dev mailing list