Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Can I do any of these 3 things with aspectJ

Hi Tarun,

My comments are below.

Ron Bodkin
Chief Technology Officer
New Aspects of Security
m: (415) 509-2895

> ------------Original Message-------------
> From: "Tarun Sharma" <t_sharma@xxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Tue, Sep-9-2003 12:52 PM
> Subject: Re: [aspectj-users] Can I do any of these 3 things with aspectJ
> 
> Hi Ron
> 
> I greatly appreciate your response, please see my comments for your
> questions, below.
> 
> On Mon, 8 Sep 2003 11:24:38 -0700, "Ron Bodkin" <rbodkin@xxxxxxxxxxx>
> said:
> ... The only definate thing I think is
> execution or similar kind. 
As Jim pointed out, it's impossible to change the type of an object constructed without access to the call site.

>...Yes, factory could have been one option.? But
> to enforce this design to the users of the framework might not work in my
> case.
You can provide your own factories. Then make your constructors package-default, so users won't call them. You could even make them private and either include a public factory method in each class or use reflection to access them from another class.

You could also write an enforcement aspect to make it an error for their code to call the constructors. But if you were willing to ask your users to compile aspects into their code, you could weave the calls :-)

What exactly are you trying to do in the default constructor? Can you just make it private to prevent calls?

> > This has the consequence that the private field will in bytecode have
> > greater access (public).
> 
> Are there any problems with that, since this I guess would be done at the
> weaving time.? Oh I see, do you mean then it could be possible to use
> that public fields accidently at other places without compile errors.?
If you're compiling with AspectJ against the sources, that wouldn't be a problem. However, the way AspectJ 1.1 implements privileged access to privates is to create public static get and set methods that can be used to directly get and set the value of the private (e.g., public static int ajc$privFieldGet$PrivAccess$Private$x(Private private1),
public static void ajc$privFieldSet$PrivAccess$Private$x(Private private1, int i)). It's not likely you'd use these by mistake. But if you are using library classes (e.g., from a jar file), it is possible to discover and use these methods.

> > I'm not clear why the use of reflection didn't work for you either. Can
> > you give the error that results. Is the problem that AspectJ is mangling
> > the name of the field?
> 
> I am  not sure where exactly the problem lies, but I got
> IllegalAccessException when I try to set the instance field value to some
> new value.

Ok, I read your original problem again and I think I understand what's happening. The code you are writing in the inter-type declaration runs inside the aspect. When you're using reflection, it works on the type system of the Java VM, not that of the AspectJ language. So to allow access to that Field, you can call setAccessible on the field in the inter-type declaration.

This is an area where a future AspectJ enhancement would be helpful, in providing a reflection API that mirrors the language semantics. But I don't think that's going to be coming out any time soon.

Ron


Back to the top