-
Enhancement
-
Resolution: Won't Fix
-
P3
-
5.0
-
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
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
- relates to
-
JDK-5038056 apt must be able to operate on incomplete source files
- Closed
-
JDK-6403459 JavacProcessingEnvironment should know if parser errors occurred
- Closed
-
JDK-6403465 javac should defer diagnostics until it can be determined they are persistent
- Closed
-
JDK-5052910 need option to turn javac errors into apt errors
- Closed