JDK-5060009 : Tidy up the case where a superclass is generated by apt
  • Type: Enhancement
  • Component: tools
  • Sub-Component: apt
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-06-08
  • Updated: 2006-03-31
  • Resolved: 2006-03-31
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
###@###.### 2004-06-08

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-beta2"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
  Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)

Does this problem occur on J2SE 1.4 or 1.4.1 or 1.4.2?  Yes / No (pick one)
  N/A

Operating System Configuration Information (be specific):
  Win 2K  / N/A

Hardware Configuration Information (be specific):
  N/A

Bug Description:
  Request For Enhancement. Tidy up the case where a superclass is 
  generated by apt

  A. Existing Behaviour:

  Given an Annotation processor for @Generate which generates source 
  code for class B

  When the annotation processor processes the following code

  @Generate class A extends B { }

  1. An error is generated on the 1st pass for B (which doesn't exist)
  2. The processor runs and generates B
  3. apt compiles both A and B successfully.
  4. Inside the annotation processor for @Generate, when executing the 
     following ...
	ClassDeclaration ADecl = (ClassDeclaration)env.getTypeDeclaration("A");
	ClassType BType = AClass.getSuperclass();
	ClassDeclaration BDecl = BType.getDeclaration();
      ... 
  BDecl is null (because there is no declaration for B yet)
  BType has no direct method for determining its name. You have to parse
  BType.toString(), and strip off the leading descriptive word 
  and since the exact form of toString is not documented, this may not be
   compatible in future versions.

  B. Request For enhancement
  1. It would be quite nice if the error generated in 1 above was "hidden" until      (it still existed in) the final compile.
  2. It would be nice if there was a more trusted mechanism to get the name of
     a Type whose Symbol cannot be found. It is probably correct that
     ClassType.getDeclaration() returns null.
  3. A side effect of this experiment is that the javadoc for 
     ClassType.getSuperclass() should state that the return type is "this" 
     in the case where ClassType.getDeclaration() returns null.

Steps to Reproduce (be specific):

(Note: The names above have been changed from those in the example below)

Unpack the attached jar file containing directories (contained scripts 
are for Win 2K)
	
    build   - where the jar file containing the annotation, apt factory,
              processor and manifest gets created
    src	- where the source code for the annotation apt factory and processor are
    t-c-k - where the test classes to compile against the jar file are
           (including a script to run the test)
    tools - contains a batch file to build the jar file from the src directory

run tools\build.cmd
run t-c-k\runtests.cmd
###@###.### 10/28/04 01:25 GMT

Comments
EVALUATION Addressing this issue in JSR 269 is being tracked via bug 6403465; apt itself will not be enhanced with the suggested improvements.
31-03-2006

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
23-07-2004

EVALUATION Comments on a couple of the issues: > BType has no direct method for determining its name. You have to parse > BType.toString(), and strip off the leading descriptive word > and since the exact form of toString is not documented, this may not be > compatible in future versions. The implementation of toString() does not add a leading descriptive word, so toString() should return the type name itself. As a practical matter this is safe, but the point is well taken that there's no documented way to get the name. > 3. A side effect of this experiment is that the javadoc for > ClassType.getSuperclass() should state that the return type is "this" > in the case where ClassType.getDeclaration() returns null. It's not the case that the unknown type and its superclass are represented by the same object. They are, as a quirk, given the same name, due to javac's internal representation of unknown types, and Types.isSameType() will indicate that they are the same type. This one is mostly a documentation issue. Unknown types need to be more prominently documented. Currently in the DeclaredType documentation it does explain that method calls on unknown types will not in general return useful results, but this information is buried too deeply. ###@###.### 2004-06-08 This bug is related to 5038056 "apt must be able to operate on incomplete source files" -- compilation "errors" on the initial source files should be surpressed as long as the "-nocompile" option is not present. In other words, allow the final javac run to report any syntax or typeing errors. However, there may also be cases were any malformed source should be treated as an error, see 5038056. ###@###.### 2004-06-10 Will reconsider for a post-Tiger release. ###@###.### 2004-07-21 ###@###.### 10/28/04 01:25 GMT
10-06-2004