I have found GCJ to be one of the best methods for bootstrapping
OpenJDK. No other method of adding support for new architectures that
does not involve working closely with OpenJDK upstream is known to me.
It is, of course, possible to add any architecture without the use of
GCJ, but if one wishes to rely on as few prebuilt binaries as possible
and minimize the chain of trust it is very hard to avoid the use of
the GCC's java front end.
I would also point out that removing GCJ would invalidate existing
work on the GNU Classpath project. While most development now takes
place on OpenJDK, Classpath provides a clean and minimalist
implementation of core Java functionality, notably cryptographic
interfaces.
Besides my personal interest in GCJ and GNU Classpath I would like to
reference Linus' opinion on removing code from the kernel, as I feel
it is very applicable going forward. As long as one user benefits from
some functionality he will not remove it. I suggest major GCC features
should be treated the same way.
"So if we actually have a user, and it works, then no, we're not
removing EISA support. It's not like it hurts us or is in some way
fundamentally broken, ..." - Linus.
http: //marc dot info/?l=linux-kernel&m=142173458609850
Many of the users of GCJ and GNU Classpath do not know they are users
and, even if they do know, are not aware that it is being considered
for removal from the GCC nor aware of this mailing list. The GNU Java
frontend is often the only usable "JRE" for poorly supported, old, or
very new systems. Users of these systems need Java environments first
produced with GCJ or GCJ itself.
That the Java capabilities are not receiving development does not mean
they are not useful, nor is that a good reason to remove them. Please
allow GCJ to continue to exist in the GCC and provide what little
maintenance it may require. It is entirely possible the frontend may
experience renewed interest in the future.
Respectfully,
R0b0t1
