If we want to write a language translator that translates one language
to another language (Java Source Code or Byte Code) that runs on JVM,
which of the following approaches is better?

1) Non-Java Source Code -> Language Translator -> Java Source Code
2) Non-Java Source Code -> Language Translator -> Java Byte Code
please advise. thanks!!

From:	Mohd Hanafiah Abdullah
Subject:	Re: How to translate a language that runs on JVM?
Date:	12 Jan 2005 22:55:19 -0500

wrote:
>If we want to write a language translator that translates one language
>to another language (Java Source Code or Byte Code) that runs on JVM,
>which of the following approaches is better?
>
>1) Non-Java Source Code -> Language Translator -> Java Source Code
>2) Non-Java Source Code -> Language Translator -> Java Byte Code
>please advise. thanks!!

I would go with (2), in fact I did. It's a C to Java byte code
translation. I did consider C to Java source (1) but worried about
the crypticness of the resulting Java source.

The compatibility issues between Java byte code and other languages
such as C are real and challenging, but it's solvable. The
performance is also a concern, but so far by utilizing the techniques
in register allocation (graph coloring) I've been able to maximize the
use of JVM's local variables which I treat as if they are registers,
instead of having to access the large array of int I created to mimic
memory. This reduces code size somewhat and also makes it faster than
accessing the large array of int everytime a C variable is referenced.

Napi
--
http://www.axiomsol.com
http://www.cs.indiana.edu/hyplan/napi.html

From:	Paul Cager
Subject:	Re: How to translate a language that runs on JVM?
Date:	9 Jan 2005 20:55:25 -0500

jrefactors@hotmail.com wrote:
> If we want to write a language translator that translates one
language
> to another language (Java Source Code or Byte Code) that runs on JVM,
> which of the following approaches is better?
>
> 1) Non-Java Source Code -> Language Translator -> Java Source Code
> 2) Non-Java Source Code -> Language Translator -> Java Byte Code
> please advise. thanks!!

I would say it is generally better to translate to Java code and let a
Java compiler translate that to Bytecode. Although Bytecode is fairly
user-friendly, generating it still involves a lot of unrewarding
tedium. Let the Java compiler do that for you, leaving you to
concentrate on your own translator.

There are a few problems with this approach though:

* You will obviously have to install a Java compiler on your
target machines.
* Starting up the Java compiler may make the whole translation
slower (maybe Jikes would be the best bet?)
* You might not feel like you have written a "proper" compiler!

Have you considered JavaCC as a Parser generator by the way? It fits
nicely in with the "generate java code from similar source" approach.
I'm not sure if this would be useful for you or not.

Paul

From:	glen herrmannsfeldt
Subject:	Re: How to translate a language that runs on JVM?
Date:	12 Jan 2005 22:55:44 -0500

Paul Cager wrote:
(snip)

> I would say it is generally better to translate to Java code and let a
> Java compiler translate that to Bytecode. Although Bytecode is fairly
> user-friendly, generating it still involves a lot of unrewarding
> tedium. Let the Java compiler do that for you, leaving you to
> concentrate on your own translator.

I agree, assuming the language allows it. There are some useful
things that you can do in JVM but not in Java.

I am told there is a COBOL compiler generating either Java or JVM, but
I don't know which. That might make an interesting comparison.

-- glen

From:	Casey Hawthorne
Subject:	Re: How to translate a language that runs on JVM?
Date:	14 Jan 2005 00:40:25 -0500

You amy want to look at Parrot which is/will be Perl's virtual
machine. They are also planning to make other languages run on
Parrot.

I don't know if Parrot will be -- faster/more flexible/easier to
develop for other hardware/OS -- than the JVM!

>http://www.wellho.net/solutions/perl-parrot-perl-s-new-virtual-machine.html

Translating a language directly to the JVM or Parrot (instead of an
intermediate language) will save time and space; as long as you do it
correctly.

--
Regards,
Casey

From:	Seokwoo Choi
Subject:	Re: How to translate a language that runs on JVM?
Date:	9 Jan 2005 20:49:26 -0500

Java language has more restrictions than Java bytecode,
for example control flow commands, method definitions.
But we usually don't use that features and I found them only in obfuscators.
I suggests #2 approach.
Programming will be simpler and can skip one step (java -> bytecode).

From:	sgganesh at gmail.com
Subject:	Re: How to translate a language that runs on JVM?
Date:	9 Jan 2005 20:49:12 -0500

I would say that, it depends on the level of abstraction of your
"Non-Java Source Code". Based only my experience in writing a Java
compiler and parts of a JVM (for the purpose of learning) it appears
to me that JVM was originally designed keeping Java as the only source
language in mind. However, note that there are translators for more
than a dozen languages available targetting JVM.

There are many portions in .class file format that makes writing
translators for other versatile languages to JVM difficult, if not
impossible. For example, consider directly translating C++ programs to
..class files: things like not having support for multiple inheritance
are obvious reasons, but there are many subtle language features, for
example, how const and final are treated in C++ and Java; also the
runtime allocation and memory models aren't just compatible. The JVM
specification mandates that the Java security model is adhered to, and
hence generating valid .class files is non-trivial (particularly when
the source language is not Java, but something different).

So, it depends on the level of abstraction your non-java source code
is and how close it is to the semantics of Java. If the semantics is
closer to Java, and significant information need not be lost when
expressed as Java programs, the first option is fine (your translator
would be simple in that case). In the other case, the second
alternative is better. In the second case, you would need to refer the
Java virtual machine specification book from Sun. The "Inside Java
Virtual Machine" book by Bill Venners will also be handy.

-Ganesh

From:	A Pietu Pohjalainen
Subject:	Re: How to translate a language that runs on JVM?
Date:	12 Jan 2005 22:55:58 -0500

sgganesh@gmail.com wrote:
> There are many portions in .class file format that makes writing
> translators for other versatile languages to JVM difficult, if not
> impossible. For example, consider directly translating C++ programs to
> .class files: things like not having support for multiple inheritance
> are obvious reasons, but there are many subtle language features, for
> example, how const and final are treated in C++ and Java; also the
> runtime allocation and memory models aren't just compatible.

Writing a C++ compiler targeting to JVM would be difficult (well,
writing such a compiler is difficult in case of any backend), but not
impossible. The discussion above applies to the .net-platform as well;
the type system doesn't have support for multiple inheritance, but still
there are compilers for languages (C++, Eiffel) that require multiple
inheritance, targeting to that platform.

I believe that the trick on implementing multiple inheritance on
presence of single inheritance is to implement a type system private
to the compiler instead of using the platform provided one. This
information is based on John Gough's book 'Compiling for the .NET Common
Language Runtime (CLR)', pages 349-352.

br,
Pietu Pohjalainen

From:	VBDis
Subject:	Re: How to translate a language that runs on JVM?
Date:	9 Jan 2005 20:49:46 -0500

jrefactors@hotmail.com schreibt:

>If we want to write a language translator that translates one language
>to another language (Java Source Code or Byte Code) that runs on JVM,
>which of the following approaches is better?

If your language is sufficiently Java compatible, then a textual
translation into Java may be easier to implement, and certainly is
much easier to debug, due to the readable output.

Otherwise JVM bytecode is equivalent to the machine code produced by
native compilers. The only advantage here is the simplicity of the VM,
that allows to exclude some optimizations that are suggested for other
machines (register allocation...).

DoDi