[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspectj-users] Intertype Questions after porting to 1.1.1
- From: Paul Christmann <paul@xxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Feb 2004 11:36:39 -0600
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
My apologies... I scanned bugzilla, but didn't see something that
pertained to either of what I was writing. I guess perhaps I need new
glasses to help me read better.
Ron Bodkin wrote:
1. It seems that I can no longer invoke intertype methods from
code that is not compiled by aspectj. Is that true?
It's a known bug for 1.1.1 (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=43972) that is fixed in
There is also a work-around that Eric Jain devised (see
This work around suggests using inner interfaces, which I tried but
couldn't get to work. For the time being, I just moved the methods onto
the classes, and can live with that. Once there is a later release, I
may move them back to the aspects.
2. Introduced constructors seem to not invoke initializers on the
This is "considered the correct behavior"; see bugzilla bug 46282
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=46282) and/or start a
discussion about why ITD constructors are important and this should
be fixed. It seems like another important use case where preserving
source information would help in the weaving phase... Note that this
is a problem with all ITD constructors, whether called directly or by
That's odd. With the simple test case that I wrote, I only could
reproduce it with reflection. Code that directly called the introduced
constructor seemed to work.
Reading the bug in eclipse, I found this note:
If you have an example of a real system where you need inter-type
constructors and the current behavior is causing you problems please
send it to aspectj-users for discussion
I'll at least mention why we were doing this (using introduced
constructors): We use a 3rd party library (castor,
http://www.castor.org) to serialize our objects. To do this, we write a
mapping file that maps our objects to xml elements with attributes. The
castor magic uses reflection, and requires public classes and public
default constructors to create the objects.
However, in our state, many of our objects have fields that we'd like to
establish as "final" variables. The way we use Castor, though, we can't
do this - castor needs a default constructor.
So, we introduced a percflow aspect that traps when castor serialization
is happening, and introduced default constructors and appropriate
"setter" methods only on that aspect. That way, the default constructor
can only be accessible while castor serialization is going on.
No other code is allowed to access the default constructor; they must
use the "well-known" constructors that take required arguments. To make
these introduced default constructors simple, we moved most of the
"initialization" code out of the "normal" constructor for an object, and
made it initializers.
So, long story short - our introduced constructors are sort of the
reverse of your example: I need to introduce the default constructor,
which I suppose could defer to the "real" constructor passing along null
But it sounds like I have 3 possible work arounds to this:
a) Move the default constructors to the class, as I did. I don't like
this, though, as it leaves open the possibility of a client of our code
creating an object in an inconsistent state.
b) Introduce the default constructor in an aspect, but explicitly call a
well-defined constructor with default values.
c) I think Castor may have changed to allow us to specify non-default
constructors as well.
Thanks for your quick response!
Prior Artisans, LLC