[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] AspectJ Custom Attributes 
Hi folks,

It is good to see such discussion here and I would like to add few comments.

I have the same feelings as Alex that AspectJ should use annotation attributes instead of inventing the custom attributes for internal things.

Answering question Andy Clement asked "Attributes are valid entries in the class file, so why would we need to change them into annotations?" there are few good reasons.

First of all, as Ron pointed out bytecode is not a closed box. There are lot of tools that need to process it and understand the data structures that may be affected by such custom processing. This is actually very similar to XML - everybody acn read and understand it without the code that originally produced it and in many cases even without documentation about its structure. For instance tool like jarjar can perform string relacement (e.g. regexp based) even if it has no clue about meaning of some substring, because user can tweak it using additional knowledge about AspectJ.

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

With growing popularity of bytecode processing tools (jarjar, cobertura, terracota, aspectj, you name it) you can't really count that proprietory attributes would survive all the transformations, so you have to recover from the case when one of the tools dropped them from the bytecode. However that won't be needed if well-known annotation atributes are used even for older pre-Java5 bytecode. Basically this would make any proprietory aspectj data much more transparent to the 3rd party tools.

  regards,
  Eugene


Ron Bodkin wrote: 
My statement was true: by default ASM will give errors when processing
bytecode with custom attributes. I didn't mean to imply that there's some
fundamental problem (I think that's how you interpreted it). Of course ASM
can handle them, but until now the default policy has been to not accept
unknown attributes, and to put the onus on the caller to specifically enable
them. I previously submitted a patch to jarjar so it can use ASM to preserve
AspectJ attributes (this is a case where preserving attributes is clearly
critical).

On the good news front, Eugene Kuleshov is proposing a means to facilitate
using custom attributes and having the AspectJ attributes supported by
default.

When this came up before on the ASM mailing list, one ASM developer asked
"why aren't you using annotations"?  In general, using annotations would
pick up better tools support. If a change like that were contemplated,
clearly 5.0 would be the release for it, although I don't think it would be
worth a delay, an increase in instability, or breaking backward
compatibility to achieve.

-----Original Message-----
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Alexandre Vasseur
Sent: Thursday, October 20, 2005 7:58 AM
To: AspectJ developer discussions
Subject: Re: [aspectj-dev] AspectJ Custom Attributes

Those are untrue statement about ASM. ASM can handle them. There is
just a need of explicit knowledge about those. This is indeed the most
important limitation in using ASM and AspectJ together.

I personally think AspectJ should move to real class level annotations
instead of custom attributes. There is no need to change a lot of
things I think. Some generic class level annotation with a single byte[] attribute is just equivalent to custom attributes - but a bit
cleaner and does not requires any special treatment. The deal is about
handling backward compatibility where needed.

Given that ASM is widespread (jarjar, many bytecode based products
commercial or not doing performance monitoring or other things etc) I
would hope a more pragmatic approach and thinking from all the AspectJ
dev team about that and ditching the old custom attributes within the
1.5 release time frame. This would solve the issue once and for all at
the right time.
That said I invite ASM folks to give it some more thinking and see if
they cannot come up quickly with a defaulted behavior that would keep
custom attributes without any special handling. That said AspectJ is
at the corner for 1.5 final, while a new version of ASM that would
handle this is not (and I remember Eric already told me this was
actually not possible given the visitor based design of ASM).

Below a code snip to preserve AjAattribute with ASM ( I cross posted on ASM list) for anyone who needs to do that:

The AJ attributes are sort of serialized bytes. I think some agnostic
wrapper can make the trick for ASM to not lose those and pass them
thru as you say.

Something like
class SerializedAttribute extends asm.Attribute
 public SerializedAttribute(final String type, final byte[] bytes) {
        super(type);
        m_bytes = bytes;
    }
// prepare one prototype for each org.aspectj.weaver.AjAttribute inner
class:
        new SerializedAttribute(AjAttribute.Aspect.AttributeName, null),
        new SerializedAttribute(AjAttribute.AdviceAttribute.AttributeName,
null),
//etc.

pass an array of  prototype when doing the ASM ClassReader.accept(...)
implement an ASM class adapter with a visitAttribute method
This one will gets called for each of the custom AJ attribute
From there you can do like: 
        public void visitAttribute(Attribute attribute) {
            if (attribute.type.startsWith(AjAttribute.AttributePrefix)) {
                if (attribute instanceof SerializedAttribute) {
                    final byte[] bytes = ((SerializedAttribute)
attribute).getBytes();
                    AjAttribute attr = AjAttribute.read(s_version,
attribute.type, bytes, null, s_handler);

to read the attribute with ASM if you need to.

If you don't, just pass it thru (hence don't implement this
visitAttribute method if using an adapter etc).

Alex