Bug 288282 - Introduction should not unnecessarily change the public interfaces of classes
Summary: Introduction should not unnecessarily change the public interfaces of classes
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-01 12:06 EDT by Matthew Adams CLA
Modified: 2013-06-24 11:02 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Adams CLA 2009-09-01 12:06:07 EDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.43 Safari/530.5
Build Identifier: 

Introduced members that are marked private in an aspect end up public members with  slightly obfuscated names.

Reproducible: Always

Steps to Reproduce:
Introduce a field marked private from an aspectj using "declare parents" into a target class.  Compile with ajc.  Use javap to view the resultant target class and observe the obfuscated public field on the target class.

From the mailing list discussion:

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); 
}




See discussion on aspectj-users mailing list with subject "Visibility of inter-type members with @DeclareMixin and @DeclareParents".

Also on nabble.com at
http://www.nabble.com/Visibility-of-inter-type-members-with-@DeclareMixin-and-@DeclareParents-ts25226224.html
Comment 1 Matthew Adams CLA 2009-10-02 10:56:14 EDT
This appears to be somewhat related:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=39457
Comment 2 Andrew Clement CLA 2009-10-02 12:07:51 EDT
try and find some time to have a discussion on this.  They are there in the interface for good reason and I've been round this loop before many years ago.  I believe it stems from the ability to access the field on the interface type.  I would need to dig through the old bug reports where I wrote all about it.
Comment 3 Andrew Clement CLA 2010-03-10 11:53:49 EST
just switching from bug to enhancement because AspectJ is currently working as designed here.

It is the declaration of a field on an interface that creates the setters/getters.  Without them we aren't able to correctly generate the code in the aspect that corresponds to a reference to a field on the interface. 

You can't write Java code that would deal with an instance field on the interface (eg. the 'return bar' below) - so a getter/setter pair are generated on the interface and then we can generate real code for 'return bar'.  The instance field cannot be hosted in the interface, it can only be hosted in a real type that the interface implements.
Comment 4 Andrew Clement CLA 2013-06-24 11:02:38 EDT
unsetting the target field which is currently set for something already released