javac: not just for java?
Peter B. Kessler
Peter.Kessler at Sun.COM
Wed May 23 09:44:07 PDT 2007
I was thinking this might be useful at another level: for
multi-language files with small embedded languages. E.g.,
if I have SQL constants in my Java code, why shouldn't I
have to leave the interpretation of that to runtime? Why
can't an SQL compiler jump in at compile time and produce
bytecode, runtime calls, etc.? An easy case might be
compiling regular expressions at compile time, rather
than wasting runtime on that.
Peter Ahé wrote:
> I think Ted is on to something. If this is just to manage a shared
> code-base that supports both .java and .ksl files from different
> command, then I do not see the need to add a language object to
> context. However, if you want to create a multilingual compiler (mlc)
> that can compile both files at once, perhaps it makes sense:
> mlc MyClass.java MyOtherClass.ksl CoolClass.scala
> The trick would be to get all these files entered at the same time, so
> they can all have mutual references.
> On 5/22/07, Ted Neward <ted at tedneward.com> wrote:
>> Would this be just trying to keep different compilers around in memory
>> different compilation runs, or are you trying to allow for multiple
>> compilers being invoked as part of one compilation pass? The former would
>> seem MUCH more approachable than the latter....
>> Ted Neward
>> Java, .NET, XML Services
>> Consulting, Teaching, Speaking, Writing
>> > -----Original Message-----
>> > From: compiler-dev-bounces at openjdk.java.net [mailto:compiler-dev-
>> > bounces at openjdk.java.net] On Behalf Of Jonathan Gibbons
>> > Sent: Monday, May 21, 2007 10:32 PM
>> > To: compiler-dev at openjdk.java.net
>> > Subject: javac: not just for java?
>> > OK, here's the wacky thought for the day ...
>> > With KSL, you can experiment with your own "wacky" language features.
>> > Except that that if they're wacky you can't call it Java. But if you
>> > are still targeting the JVM, wouldn't you want to be able to mix n
>> > match Java code and your wacky language, assuming they were
>> > sufficiently interoperable.
>> > OK, so the premise might be a bit contrived, but assume it for now ...
>> > What would it take to mix n match "sufficiently similar" languages in
>> > javac?
>> > Internally, javac is divided into a number of components,, such as
>> > the scanner (or lexer), the parser, "enter" and "member-enter",
>> > "attr", "flow", and so on all the way through to "gen". These
>> > components can be divided into two groups, according to whether they
>> > are language specific or not. Informally, if the components come from
>> > the "parser" or "comp" packages, that means they are very specific to
>> > the Java language. If they come from "code" or "jvm", they are closer
>> > to the JVM.
>> > Currently these components are held as singletons in the Context
>> > object. But imagine if we introduced a new Language object, that
>> > contained the language specific components, and then could put a
>> > number of Language objects in the context, indexed by a Language
>> > Kind, possibly derived from the filename extension of a source file.
>> > (This would need to be expressed in JSR199 terms for the
>> > JavaFileManager of course.) So then, when javac goes to parse a file,
>> > it uses the file extension to determine a Language object from which
>> > it can get a Scanner and Parser. The result would be an object that
>> > could be processed through the rest of the compiler's pipeline, using
>> > language-specific components as needed, and using language
>> > independent components for the types and symbols, and eventually
>> > gen. If the languages are sufficiently similar or compatible (no-TM)
>> > with Java, it should be able to define how such source files could
>> > interoperate with Java source files, and be compiled alongside them.
>> > This is clearly just a wacky idea, barely half-baked, and we would
>> > have to resolve issues like locating source files on the source path
>> > for missing class files. And the javac spec purists might grumble
>> > and we'd have to call it something else (kslc, anyone?) but it might
>> > prove a way to mix n match KSL variants with real Java code.
>> > -- Jon G
More information about the compiler-dev