On Mon, Dec 21, 2009 at 4:23 PM, Per Bothner <[email protected]> wrote: > If the return type of an exported method depends on type inference > and that inference may have circular cross-module dependencies, > my reaction is: Don't do that. You can't define a stable API > that way, at least not a library API. It might be OK for a > module-private method (in the sense of JSR-294 - i.e. a group of > classes that go together), but the use-case where you might > need to infer return types across language boundaries seems > pretty low-priority.
Sure, I agree with that. It's an outlier, in any case. >> And if .class files are enough, I will happily concede that they're >> the best approach for the problem. Like I said...I don't care! >> Ultimately a joint compiler that knows how to work with all those >> .class files (or with a mirror API to language-specific data) and >> trigger a subsequent "complete" compile still needs to be there, which >> is the point of this thread. > > And I'll happily concede using a standard API might work better. > A key issue is how easy it is to fit javac into the framework. > In theory we have the option of adding functionality to OpenJDK, > but of course we really want something that can work with Java 6 > (or even Java 5, though that's lower priority). I think we need more than that: there's other non-Sun-javac Java compilers out there, that would presumably want to participate. Maybe we by presenting stubs we'll be good enough, but having a standard interface for each language that can 1. generate stubs and 2. trigger final compilation would at least be necessary. And having a per-language API that could get mirrored types out would be even better, since that feeds into IDE support for recognizing where type and method declarations are coming from without having to regenerate stubs all the time. I don't think it would be very hard to implement the javax.lang interfaces for any language that wants to expose Java types. If we ignore the circular type-inference problem for a moment, that would be almost as easy to do as generating stubs. - Charlie - 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.
