Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5060009

Tidy up the case where a superclass is generated by apt

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Won't Fix
    • Icon: P3 P3
    • 6
    • 5.0
    • tools
    • apt
    • x86
    • windows_2000

      ###@###.### 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

            darcy Joe Darcy
            tyao Ting-Yun Ingrid Yao (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: