This is a technical problem, but when you run into it, something is 
probably wrongly designed.
And maybe one can simply solve it by programming against interfaces.

Am Sonntag, 2. März 2014 21:54:57 UTC+1 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. 
>
> 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] <javascript:>   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.

Reply via email to