Bug 47919

Summary: Respect final classes
Product: [Tools] AspectJ Reporter: Wes Isberg <wes>
Component: CompilerAssignee: Adrian Colyer <adrian.colyer>
Status: REOPENED --- QA Contact:
Severity: enhancement    
Priority: P5    
Version: 1.2   
Target Milestone: 1.5.0 M4   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Wes Isberg CLA 2003-12-02 15:31:17 EST
Making inter-type member or parent declarations on a final class arguably
violates encapsulation.  Bytecode weaving makes this both more likely, and more
problematic.

For such declarations in a non-privileged aspect, the compiler should issue an
error.  This gives us a bright-line rule of thumb that encapsulation will be
preserved when not using privileged aspects.  However, this is not
backwards-compatible with some existing programs.  While it would be easy to fix
the code (if one has the source) by declaring the aspect privileged[1], doing so
means one is not protected from or notified about unintended access control
violations.

An alternative to making it an error is to use an XLint message, preferably with
a default level of error.  

Also, supporting "privileged" as a finer-grained access specifier would avoid
some of the problems above, and might be worth considering on its own merits:

aspect A {
  declare privileged parents: FinalTarget implements Runnable;

  public privileged boolean FinalTarget.run() {...}


  private fixup(privileged Foo foo) { // parser-eek!
      foo.privateVariable = null;
  }
  ...
}

In any case, we should document the issue.
Comment 1 Adrian Colyer CLA 2005-03-22 08:32:01 EST
The discussions around this issue continue to circulate periodically. It would
be nice to give AspectJ programmers who want some level of assurance/control a
way to get it. Perhaps a -XrespectFinal[Types?] flag in AJ5 M4 that does not
allow modifications to final types? (Caution - the issue is quite tricky, we
have to separate out what the 'user' considers a modification - such as an ITD,
or maybe execution advice, from modifications that arise out of current
implementation strategies (e.g. a perthis() aspect where 'this' has a final
type). It feels like the latter should be allowed even though it touches the
bytes of the final class. Otherwise we end up with semantics that are based on a
current implementation.
Let's look at it as part of the M4 milestone.
Comment 2 Adrian Colyer CLA 2005-08-26 10:50:34 EDT
We're not going to get to this in AJ 1.5.0. Marking as "LATER" for consideration
in 1.5.1 and future release planning.
Comment 3 Eclipse Webmaster CLA 2009-08-30 02:48:43 EDT
LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated.