GNUJavaCompiler

Status: No active volunteers.

The purpose of this project is to make the ​GJC (GNU Java Compiler) work with RTEMS. RTEMS is supported as a target in GCC so it is expected that the primary development focus of this project will be to adapt the run-time library to RTEMS. Since the GNU Ada and C++ run-times are already ported to RTEMS, there are examples to work from for many issues. Also if the porter assumes it is using the POSIX thread interface, it is very likely that the GNU/Linux port will be a good reference.

This project will consist of the following phases:

• Port GJC Run-time to RTEMS. The port will be target CPU architecture independent. Just like the GNU Ada tasking support, this should be written in a processor architecture manner using portable API calls provided by RTEMS.
• Run GJC Test Suite. We are already running the general GCC C/C++ testsuite and the Ada run-time tests. So there is precedence and help available.
• Submit modifications to GCC and RTEMS Projects

Here is a list of technical details from Tom Tromey, the GCJ maintainer. A lot of stuff in libgcj is optional. So, a minimal port can be made pretty quickly. From memory:

• The GC must be ported. This can be difficult but usually is not, since it has already been widely ported.

• For a good libgcj port, libffi must be ported. It already runs on most architectures though. This would only matter if the target is a new architecture or if the target has a different ABI. A libffi port has two parts. Each is optional. First, the normal libffi API is used for reflection and one direction of JNI. Second, the libffi closure API is used for the interpreter and JNI->Java calls. libgcj will configure and build just fine if these are missing.

• For an excellent libgcj port, you have to write code to turn a signal into an exception. This is some hairy unwinding stuff, partly in gcc and partly in libgcj. However, there is an option to have gcj add explicit checks where needed, for platforms where this is not possible. [NOTE from joel: This is the technique also used by GNU Ada so there should be existing code to leverage and share between the GNAT/RTEMS port and the GJC/RTEMS port.]

• libgcj's thread layer must be ported. This is usually easy. The POSIX "flavor" already works in a lot of places. Note that this can affect the GC as well. This part can actually be disabled, but you can't run much java code without threads.

• File I/O, sockets, and other stuff like that should be ported. Some of this can be disabled for less-capable targets. Again, the POSIXy code should work fine.

• For the full pull, port AWT. This is a lot of work and, really, nobody ever bothers.

There was a previous effort to do this but it was not submitted to the GCC Maintainers. At this point, it was against such an old version of gcc that it would probably have to be used as a reference more than a code base.

This is expected to be a good Google Summer of Code project.

The contributor MUST have or file Free Software Foundation paperwork and it is assumed that this code will be contributed to GCC.