Am 02.03.2014 21:54, schrieb Per Bothner:
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.
Oh this is funny, because just a few days ago, not only we got approved as organization for GSOC2014, but also got a student interested in writing an advanced joint Groovy-Java compiler. But if that is going to happen or not is not sure yet. The stub solution we currently use has bad limits, like most of our transforms not being respected in this process. So this projects aims at bridging the asts of both compilers, without us really knowing if javac can be controlled enough to make this happen.
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.
We worked around that I think by first resolving classes in our Groovy code, where possible, plus leaving the import statements. Then we generate the stubs, let javac compile everything and then groovyc picks up missing classes from there to produce the final groovy classes. This works only because groovy and java import statements work very similar. And we still sometimes get into situations that this logic cannot resolve.
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.
For eclipse we have something like this already actually. And while there is a command line eclipse compiler for a long time already, we have the problem, that jdt does not expose everything as needed. So a modified JDT is required. The goal of our project would be to have something more lightweight... in example not have to ship a modified jdt
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.
It was tried several years ago already to get some kind of framework to do that and have for example a compiler for code mixing java, groovy and scala. But there was not much interest apart from "that would be good" on a jvm languages summit. It would be good if there is now more interest.
Frankly, if I had the time, I would have long written that (or failed doing so;) )
bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org -- 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 jvm-languages+unsubscr...@googlegroups.com. To post to this group, send email to jvm-languages@googlegroups.com. Visit this group at http://groups.google.com/group/jvm-languages. For more options, visit https://groups.google.com/groups/opt_out.
