JDK-4813736 : API to compiler ASTs (aka Tree API)
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 1.4.1,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-02-05
  • Updated: 2017-05-16
  • Resolved: 2005-10-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
6 b57Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Name: rmT116609			Date: 02/05/2003

This request for enhancement could potentially help in a
number of development efforts.  In my case, it would help
with serialization efforts.

Basically, I'd like some way of accessing the compiler (or
a compiler look alike) to get well formatted details of a
class.  The reasons I feel this belongs in core java
functionality are:
   1) the compiler ALREADY has to reliably parse classes,
and it gets the most stress testing; thus one would expect
it to be the "most reliable" solution
   2) likewise the compiler ALREADY is storing away class
information in "neat" datastructures that would be easy and
logical for a programmer to access*
   3) the information that one could glean from such a
feature would have a myriad of uses:
   -reliable custom serialization:
      Currently if one uses a custom serialization solution
(Castor, in house code...) one still has to figure out how
to map the class to the serialization format in question.
This shouldn't involve touching code (like xdoclets
comments that are metadata for generating castor
mappings "automatically") as this adds a new layer of
testing and debugging, and one may want to target 3rd party
code without having to rewrite it.  Likewise, 3rd party
solutions (like Castor itself) are easy to confuse about
how classes map.
    -dynamic code review & tracking:
       By passing the parsed info to logic routines one
could easily and potentially automatically identify certian
issues in an evolving codebase
    -supporting code generation:
       One could use the info to automatically generate
supporting code intelligently


*Of course, the compiler is native, but all one needs is an
interface that takes its parsed and packaged info, and
wraps it up neatly in standard Java objects for

I'm not sure what would be the best way to run such an
interface.  One idea would be to have an API for
parsedClass objects- compile a program that uses the API
and then chain javac and java together like so:

java logic (javac -parse newClass.java)

Basically we run logic and as an argument we pass the
output of "parsing" a target class.

Alternately it could be a flag on java (which in turn
invokes javac with the interface)

(Review ID: 180884) 
###@###.### 2004-11-16 16:07:47 GMT

SUGGESTED FIX See http://javac.sfbay/home/pv149515/jsr199/ ###@###.### 2005-05-18 02:30:52 GMT

EVALUATION The submitter should consider using apt (Annotation Processing Tool) which exposes the necessary API for doing "reliable custom serialization" and "code generation". As for more advanced usages, such as better integration with IDEs and "dynamic code review & tracking", this is planned for mustang as part of JSR199. The final charter for JSR199 is likely to be closer to what is requested here than the abstract file system of 4164450. ###@###.### 2004-11-16 04:34:10 GMT The API should provide better abstractions for code like "int[] a, b[];" (RFE 4922732). ###@###.### 2005-04-08 08:21:35 GMT This API will not be provided as part of JSR 199. The API is targeted for Mustang, just not as part of a JSR. ###@###.### 2005-04-08 08:26:27 GMT

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang