The issue is mixed-language programming, in the sense of module A written in language L1 references members of class B written in Java, which in terms references members of A. Potentially, there may be complicated cycles and additional languages besides L1 and Java.
The "standard" solution I believe is to compile A twice: first with a "stub compiler" that ignores "module internals". This generates a skeletal A.class that can be read by javac. After B is compiled by javac, then we compile A for real to generate the real A.class. This has various problems. Compile-time performance is the obvious (having to partially compile A twice). Worse, there are limitations in the dependencies between A and B. For example, A might define a class that extends B - but you can't tell until you've read the package declaration in B.java. Better if we can do the Enter/MemberEnter phases of javac on B.java before we start compiling A.L1. And we might want to only doing a first pass on A.L1 before we get back to B.java. Things may need to be compiled on-demand, as mentioned in: http://openjdk.java.net/groups/compiler/doc/compilation-overview/ It should be possible to write a multi-language compiler tool that extends javac. That's what we did for JavaFX Script, but in that case the entire JavaFX Script compiler was based on javac. It may be more difficult to wrap an existing L1 compiler. E.g. the internal L1 compiler objects have to be mapped to javac Symbol objects. Anyone thought about this? Experimented with it? I'm wondering if it might be good Google Summer-of-Code project. I wouldn't expect a student to produce a usable tool in a Summer, but it could be a useful experiment. -- --Per Bothner [email protected] http://per.bothner.com/ -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/groups/opt_out.
