Re: [asm] asm as a compiler?

[Ville Oikarinen <ville@xxxxxxxxxxxxx>]

On Wed, 29 Nov 2006, Jochen Theodorou wrote:

> Ville Oikarinen schrieb:
> > Hello.
> > 
> > My question: Can asm be used (easily) as an in-memory compiler?
> 
> in the end you create a byte[] containing the bytecode of the class. The 
> in-memory compiler is the normal case then ;)
> 
> > Some background:
> > 
> > I am developing a metalanguage, and I thought it would be nice to be able
> > to generate java classes, not only source.
> > 
> > The problem with javac (and hence ant etc) is that it requires real files
> > for input and output, and I don't think it's possible to mock files
> > without some major bootclasspath hacking. So compiling _can_ be done with
> > javac, but it's awkward and slow (at least when I'm forced to use NTFS...)
> > 
> > What I'd like to do, is to wrap my generated java source objects and
> > dependency classes as something readable by a compiler (e.g.  
> > SourceProvider and ClassProvider), and then wrap the compiler's output
> > (e.g. ClassProvider) as java class objects usable in my metalanguage.
> 
> besides writing your own full compiler and a big fight with the 
> bytecode.. how about using somthing more abstract? For example 
> http://www.janino.net. You should also consider the soon 1.0 version of 
> Groovy http://groovy.codehaus.org. I don't much about your 
> metalangugage, so I can not say what would be the best solution for you. 
> It depends much on the complexitiy of your language.
> 
> 
> bye blackdrag
> 
> -- 
> Jochen "blackdrag" Theodorou
> Groovy Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
> 

Thanks for your reply.

I hope you don't mind that I quote your reply so I can keep the discussion 
public.

You are right, I don't want to implement a compiler by my own. That's why
I wrote to this mailing list :)

I am fully aware of the different languages that produce bytecde (in fact
I used Groovy as a platform for my metalanguage before it grew to a
stand-alone functional language). I am not interested in them.

I am interested in generating java source, and optionally, if I get the 
answer I hope, classes.

If this isn't easily achievable, then I settle for generating java source
with ant files and let ant continue from there.

There are many reasons why I want to generate java sources, and not only
bytecode directly. The most general reason is that my tool is a
metalanguage and thus it should be able to be used for any
transformations, including ones that produce java source, and others that
consume java source.

But generating java source has also other advantages:

- the users of the metalanguage can understand and debug the generated
java sources

- the generated java sources can be published as open "source", a model
for which I don't know a better name than my own "open implementation", in
which the real source (written in the metalanguage) is closed, but the
intermediate source is open, allowing the client to verify the
implementation.

So janino and other "almost java" compilers won't do in my case.

- Ville Oikarinen