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