Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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




On 10/19/05, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:
> I think the issue is that tools like ASM are increasingly expecting only
> Java 5 annotations for anything beyond standard Java attributes. That's not
> a good design for a java platform tool in my books, but some of them are
> taking the view that annotations are the right way to add any extra
> information. Specifically, ASM barfs with an error on AspectJ attributes and
> won't preserve them. This means that for tools like jarjar to handle AspectJ
> class files, it requires a special patch. However, addressing that is
> definitely not worth delaying the release of 5.0 in my books, and hopefully
> ASM will support the non-annotation based AspectJ attributes once the 5.0
> bytecode format is finalized.
>
> This also reminds me of the question of using Java's synthetic for generated
> methods versus AjSynthetic. I know that EMMA won't give line-level coverage
> of AspectJ bytecode because it doesn't understand AjSynthetic and is
> expecting those methods to be annotated as synthetic. I know that some other
> tools were choking on bytecode that was marked as synthetic when AspectJ did
> this. I wonder if -XrealSynthetic is a worthwhile option. Conversely, are
> those other tools just broken? Should there be a -XprivateSynthetic be an
> option instead?
>
> -----Original Message-----
> From: aspectj-dev-bounces@xxxxxxxxxxx
> [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement
> Sent: Wednesday, October 19, 2005 12:56 PM
> To: AspectJ developer discussions
> Subject: Re: [aspectj-dev] AspectJ Custom Attributes
>
> There is currently no plan to migrate our attributes to annotations.
> We have introduced lots of new annotations in 1.5 to support features
> like the @AJ syntax and the meta-aspect protocol (for example:
> ajcDeclareEoW), but 'internal' attributes like
> 'MethodDeclarationLineNumber' are not going to become an annotation in
> the 1.5 timeframe.  Attributes are valid entries in the class file, so
> why would we need to change them into annotations?  If it is to make
> them accessible by 'other tools' then I think the work we have done
> creating new annotation types for the MAP support is good enough,
> everything other tools should want to know about an aspect is in those
> new annotation types - take a look in the
> org.aspectj.internal.lang.annotation package...  It is a possible
> future item to look into as it would externalize more clearly the form
> of everything we put into a classfile...but I don't think it'll happen
> soon.
>
> Andy.
>
> On 19/10/05, Eduardo Rocha <eduardorochabr@xxxxxxxxx> wrote:
> > There is a thread in the ASM mailing list about AspectJ custom attributes,
> > those contained in the class org.aspectj.weaver.AjAttribute:
> >
> >  http://www.objectweb.org/wws/arc/asm/2005-10/msg00006.html
> >
> >  Currently ASM doesn't support these attributes, since there is an
> > expectation that these attributes get converted into common annotations.
> >
> >  So what AspectJ 1.5 final will bring? Keep these custom attributes or use
> > common annotations?
> >
> >  Eduardo
> >
> > _______________________________________________
> > aspectj-dev mailing list
> > aspectj-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> >
> >
> >
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>

Back to the top