Charles Oliver Nutter wrote: > On Sun, Dec 20, 2009 at 8:28 PM, Per Bothner <[email protected]> wrote: > >>The problem is picking a representation. A .class file is one valid >>well-understood representation. An API might be better, but designing >>one for multiple languages is probably not feasible. (Remember CORBA.) >> >>I think the best choice for an API may be javax.lang.model.*. >>It very Java-centric, but that's probably the best we can do. >>It has the big advantage that javac already implements it. > > > I was actually thinking along the lines of the mirror API that the > Annotation Processing Tool uses: > > http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/overview-summary.html
That private API has been replaced by the standard Java extension API Per referred to (javax.annotation.processing.Processor processes javax.lang.model.element.TypeElements). http://java.sun.com/javase/6/docs/technotes/guides/apt/index.html And as I said, if you want to do something like Groovy's unified compiler, it is done by generating .class files (as Per also suggests) and could be implemented in a standard manner integrated with javac using javax.tools. That doesn't mean that .class files have to be generated, because JavaFileManagers can provide the bytes any way they please. And if you want JDK 1.5 compatibility, the javax classes can be jarred up as needed, like is done for JSR-223 with LiveTribe's implementation (which includes public Maven 2 artifacts). It is used by both Groovy and Jython for compiling on JDK 1.5. Jim -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
