On Mon, Dec 21, 2009 at 6:34 AM, Jim White <[email protected]> wrote:
> Charles Oliver Nutter wrote:
>> 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

Ok, now I see where the right bits go in the javax.lang stuff...I was
thrown off initially because there's far fewer interfaces, but they
appear to have been condensed a bit (ExecutableElement for all
method-like things, and so on). So using javax.lang plus a jarred-up
backport version of it would be just as good as apt, and javac would
speak it already if you used the right javac. We're making progress
now :)

The "javac implements these interfaces" bit would ned to be figured
out for Java 5 users, of course.

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

So your suggestion would be to use the javax.tool interfaces and
produce dummy stubs live for the compilation process? That's not bad I
guess, but it seems like it would be a lot cleaner and less hacky to
generate the appropriate interfaces and coordinate them directly. Need
to think about that a bit.

In any case, there still needs to be a top-level compiler coordinating
the generation of either stub .class files or javax.lang.element data
and then eventually triggering the "final" compilation, and that
top-level needs to be agnostic of any of the languages. So we're still
in the same boat as far as needing a coordinator.

- Charlie

--

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.


Reply via email to