Charles Oliver Nutter wrote: > Ok, I think it's time we formally got some of our compiler mavens > together to create a common AOT compiler infrastructure we can all > plug into. This was discussed briefly at JVM-L, but I'm not sure > anything has come of it yet. > ...
You don't mention javax.tools, but it seems to me that it almost does what we want here. And since it is properly named (javax.tools rather than java.tools) it can be supported on JDK 1.5 (just like JSR-223). For example, it provides the key interface for supplying source files and class files given class names (JavaFileManager.getJavaFileForInput). The trouble of course is that it is only concerned with a single source file type. But that may be OK becase each compiler can have a JavaFileManager in which JavaFileObject.Kind.SOURCE is it's respective source. Naturally the Kind.CLASS files would be the collective set, mapping the stubs out as it goes along if using sequential compilation. Or perhaps you'd stub everything and then compile each language with all the stubs except the ones for it? That would be simplest and easiest to analyze. But if you've got enough memory (including distributed compilation) then multiple compiler JavaCompiler.CompilationTasks might be run in parallel. Whether that would wind up doing the right thing dependency-wise I'm not sure without working through a design and examples. Certainly stubs simplify such things and avoid recursion. I'm actually more interested in more general dependency schemes based on RDF, but having something for JVM languages would be dandy and would be useful in IFCX Wings. Jim --- http://www.ifcx.org -- 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.
