This is the mail archive of the
mailing list for the GCC project.
java bytecode considered bad
- To: <gcc at gcc dot gnu dot org>
- Subject: java bytecode considered bad
- From: Trent Waddington <s337240 at student dot uq dot edu dot au>
- Date: Wed, 21 Feb 2001 03:19:22 +1000 (GMT+1000)
Following is a dialog I have had with RMS over the last few weeks. The
skinny of it is that RMS thinks having gcc both generate and accept as an
input java bytecode allows folks to do nasty proprietary things with gcc
so he's not interested in the backend for the jvm which I wrote 18 months
ago (and doesn't think anyone else should be). I have tried to explain
that java bytecode (especially the stuff I generate) is not a good
intermediate language... I'll let the list handle it.
>From email@example.com Wed Feb 21 03:11:22 2001
Date: Wed, 7 Feb 2001 08:00:02 +1000 (GMT+1000)
From: Trent Waddington <firstname.lastname@example.org>
Subject: java backend
Hi. I dont know if you remember me but I worked on a java bytecode
backend to gcc which was released early last year. At the time I was
instructed that it would be impossible to get the copyright on the backend
assigned to the FSF. I would like to try again to obtain the copyright
assignment as the ownership of this code is no longer a priority to the
university that I was working for at the time. As far as I know gcc does
not currently support the generation of java bytecode [if this is
incorrect I would love to know where I can read more about it!]. Since
the release of this backend I have constantly received email from
interested parties wishing to compile c/c++ to the java virtual machine.
An addition of a java bytecode target to gcc would facilitate this if I
>From email@example.com Wed Feb 21 03:10:12 2001
Date: Sat, 10 Feb 2001 08:59:32 -0700 (MST)
From: Richard Stallman <firstname.lastname@example.org>
Subject: Re: java backend
If it is possible to compile languages such as C into Java byte codes,
I see a great danger. The danger is that people will use Java byte
codes to hook GCC up to proprietary back ends and proprietary front
ends. They could also generate Java byte codes, run a proprietary
optimizer, and feed the result back into GCC. In effect, the support
for Java byte codes would undermine the goals of the GPL.
If your changes really do make such activities much easier, more
feasible in practice, then I think it would have been better if you
had never implemented the feature. And now it would be better now if
you take these changes off your web site, and don't mention that they
exist. Of course, someone else really determined could redo the work,
the extra burden of doing so might dissuade people from trying.
Did we discuss this previously? I don't remember, because my memory
is not as good as it was. If we did, I will search for the old mail.
>From email@example.com Wed Feb 21 03:16:35 2001
Date: Wed, 14 Feb 2001 10:13:28 -0700 (MST)
From: Richard Stallman <firstname.lastname@example.org>
Subject: Re: last reply
To me it appears that you believe java bytecode is an intermediate
language, and compiling to an intermediate language is not the goals of
gcc because it is possible to write proprietory code that uses the
That is right. More precisely, I see that it could be used as an
intermediate language--and that GCC might be equipped with code
both to write it and to read it.
386 assembler code could also in theory be used as an intermediate
language, but (1) it would be far more cumbersome and (2) nobody is
writing code for GCC to *read* this language. These two obstacles can
certainly in principle be overcome, but that would take work, and the
work makes it unlikely. There's a big practical difference between
"You could do it inconveniently if you add a lot of other features
first" and "You can do it conveniently today, since we give you
everything you need to get started."
One thing I am not certain of. I think I recall that the Java front
end for GCC can easily read in Java byte codes and compile them.
Can you tell me for certain if that is true?