[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Visibility of inter-type members with @DeclareMixin and @DeclareParents

Hi Andrew,

If you publish a jar whose classes have introduced methods and then
you use that jar in another project, the synthetic methods are visible
via content assist in the consuming project.  I don't mind if someone
wants to go to the trouble of using reflection to access non-publics,
but I do care that the consumer of the introduced classes can see the
fact that they have been woven with new public fields and methods.
IMHO, the public interface of the woven classes should not change,
unless the change(s) is(are) to implement a new public interface, in
which case you should only see the class declaration's additional
"implements" clause and the additional public methods of that
interface.  The public consumer of a class in normal usage
(non-reflection) should not have any clue that AspectJ was used to
weave the class.

With regard to synthetic method filtering, the introduced methods
would only be filtered during content assistance in an editor that
knew about AspectJ, which is only eclipse with AJDT installed, if I'm
not mistaken.  Other editors, and eclipse without AJDT, would display
the introduced methods, which is undesirable.

If only load-time weaving were used, then this is a non-issue, but I
feel that compile-time weaving is more pragmatic, especially in
application server environments, and that's when this issue is

I don't want to ask for something that doesn't make sense.  Does it
now?  Please confirm.


On Mon, Aug 31, 2009 at 1:42 PM, Andrew Eisenberg<andrew@xxxxxxxxxxxx> wrote:
> Hi Matthew,
> I don't think that's currently possible, so you should probably raise
> an enhancement request for that.
> However, I would like to know why this is so important to you.
> These methods are synthetic and someone who wants to call them must
> either look at the byte code or have knowledge about AspectJ.  In the
> IDE, they are filtered from content assist.  And even if these methods
> were made private, they could still be accessible via reflection.
> I'm not entirely sure how security policies work, but I know they can
> be used to restrict reflective access to fields.  Can they also be
> used to restrict other kinds of access?
> On Mon, Aug 31, 2009 at 1:13 PM, matthewadams12<matthew@xxxxxxxxxxxxxxx> wrote:
>> I've noticed that introduced fields appear to be more public than I'd like.
>> Consider the following code, all in package "intro.test":
>> @Target(ElementType.TYPE)
>> @Retention(RetentionPolicy.RUNTIME)
>> public @interface HasBar {}
>> =================
>> @HasBar
>> public class Foo {}
>> =================
>> public aspect HasBarIntro {
>>        private interface HasBar {}
>>        declare parents: (@intro.test.HasBar *) implements HasBar;
>>        private String HasBar.bar;
>>        public String HasBar.getBar() {
>>                return bar;
>>        }
>>        public void HasBar.setBar(String bar) {
>>                this.bar = bar;
>>        }
>> }
>> =================
>> After compiling, the introduced String "bar" appears as a public field on
>> Foo.  When I run "javap -private intro.test.Foo", I get the following:
>> Compiled from "Foo.java"
>> public class intro.test.Foo extends java.lang.Object implements
>> intro.test.HasBarIntro$HasBar{
>>    public java.lang.String
>> ajc$interField$intro_test_HasBarIntro$intro_test_HasBarIntro$HasBar$bar;
>>    public intro.test.Foo();
>>    public java.lang.String
>> ajc$interFieldGet$intro_test_HasBarIntro$intro_test_HasBarIntro$HasBar$bar();
>>    public void
>> ajc$interFieldSet$intro_test_HasBarIntro$intro_test_HasBarIntro$HasBar$bar(java.lang.String);
>>    public java.lang.String getBar();
>>    public void setBar(java.lang.String);
>> }
>> Notice the first field, a public String field introduced by HasBarIntro.
>> Why is the field public?  Is there a way for all of the members prefaced
>> with "ajc$" to be non-public?
>> I tried to ask this question once already:
>> http://www.nabble.com/ITD-public-fields-break-encapsulation--ts25154702.html
>> Thanks,
>> Matthew
>> Andrew Eisenberg wrote:
>>> If the interface used as the introduced parent is only accessible
>>> inside the aspect (ie- it is private), then its methods should only be
>>> accessible from within the aspect.  So, your strategy below should
>>> work (however, I have not tried this out myself).
>>> 2009/8/31 João Gonçalves <jocolimonada@xxxxxxxxx>:
>>>> Using the private keyword in the factory method (for @DeclareMixin) /
>>>> field
>>>> (for @DeclareParents)?
>>>> That is:
>>>>     @DeclareMixin("ClassName")
>>>>     private static IFood create FoodImplementation() {
>>>>         return new FoodImpl();
>>>>     }
>>>> and
>>>>     @DeclareParents(value="ClassName",defaultImpl=FoodImpl.class)
>>>>     private IFood food;
>>>> Thanks. Also, in the above examples, the visibility will be private, even
>>>> if
>>>> the interface/implementation class is public, right?
>>> _______________________________________________
>>> aspectj-users mailing list
>>> aspectj-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> --
>> View this message in context: http://www.nabble.com/Visibility-of-inter-type-members-with-%40DeclareMixin-and-%40DeclareParents-tp25226224p25229677.html
>> Sent from the AspectJ - users mailing list archive at Nabble.com.
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users