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 experienced. I don't want to ask for something that doesn't make sense. Does it now? Please confirm. Thanks, Matthew On Mon, Aug 31, 2009 at 1:42 PM, Andrew Eisenberg<[email protected]> 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<[email protected]> > 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 <[email protected]>: >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > -- mailto:[email protected] skype:matthewadams12 yahoo:matthewadams aol:matthewadams12 google-talk:[email protected] msn:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
