RE: [aspectj-dev] AspectJ Custom Attributes

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

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.

-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[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
> annotations.

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

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

   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 
topic. :-)

   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.

   regards,
   Eugene

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev