If you feel you might like to contribute to the jRate project, please contact us on the developers' mailing list (and feel free to subscribe to it too!)

The jRate project is always looking for motivated people that can spend a little time or a lot to improve the project. Even if you have little or no experience working with real-time and embedded systems, compilers and runtime systems, but would like to learn, we'd be happy to show you some of the ropes and get you started.

If you have few or no technical skills, don't fret! There are non-technical but essential skills that the jRate project needs as well!---see Critical Non-Technical Tasks, below.

Financial support is also quite welcome, of course. And if you're interested in contributing to the jRate project in some other way not listed here, please drop us a line.

• Porting to different operating systems and architectures. If you are not experienced at porting software, this might be a good starting point for you. GCC composes most of jRate, and GCC is already highly-portable. So porting jRate is mostly a matter of having an available computer for testing and replacing a few function calls or configure checks.
• Squashing a few known bugs. Alas, there are a few bugs that can be reliably triggered but occur infrequently enough in software that we just haven't gotten to them yet. Also, there are places in the code that function but that we'd like to clean up if we got a chance. Either of these projects could serve as a good introduction to jRate for a new contributor.
• Converting the standard Java runtime library to be real-time-aware (partially completed). This is a large and important task. Java users have come to expect the Java class library, and they don't want to give it up when they move to a real-time platform! Some of the standard libgcj/classpath library classes are suitable for use in real-time Java, while others either rely on garbage collection or require unpredictable time to perform their tasks. Some of these have been converted, while others still are not.
• Developers' tutorials. It would be very helpful to have a few simple HOW-TOs, "best practices" documents, or tutorials showing some appropriate techniques for using jRate and the class library (and what to watch out for!) in an archetypal real-time application example.
• Completing the Real-Time Java Specification. Parts of jRate incompletely implement the Real-Time Specification for Java. Other parts of jRate are incompatible with this specification and may require redesign.

If you are interested in doing research with jRate, there are also a number of compiler/language/runtime research projects that can be performed, small or large. Some ideas off the top of my head include...

• Designing more appropriate memory subsystems.
  • Region memory management. The Real-Time Specification for Java describes a region-based memory model that is safe (i.e., no dangling pointers), but doesn't use a garbage collector. This is performed by making certain restrictions on inter-object references. The model is implemented by jRate but is found unwieldy by many application developers. There are, however, ways of limiting garbage collection, maintaining pointer integrity, and relaxing the restrictions of the Real-Time Specification for Java. However, these haven't been fully fleshed-out, and it would be a good research project to investigate the different options here.
  • Real-time garbage collectors. Currently, jRate uses no garbage collector at all. Future versions will hopefully include some garbage collection capacity, and it would be highly advantageous to use one with at least some real-time guarantees. This is a difficult problem that has considerable interest in the research community, and the implementations of solutions proposed in literature are often not released publicly, as patents are being sought. Designing and implementing a real-time garbage collector would be a huge contribution to jRate and open-source in general!
• Real-time-targetted compiler optimizations. The sky is really the limit here. Real-time and embedded systems developers would find all sorts of program analyses useful, and anything from automatic high-level code restructuring to low-level instruction selection heuristics for real-time applications could be performed in jRate with the full architectural support of GCC behind it.

Of course, it would be greatly appreciated if you would contribute the results of any research back to the jRate project! We are certainly willing to help you understand what's what in jRate to help you with your implementation work.

Besides development work, research, and other assorted hacking, the jRate project could certainly benefit from people willing to do work in other areas...

• Testing, especially on non-Linux or non-x86 platforms. We all have stock Linux desktops sitting around, but our "real" target with jRate is embedded, real-time systems. Even if you don't have an embedded system laying around, that PowerPC you do have might be useful as a jRate testing platform! After all, not all embedded processors are x86-compatible, and not all embedded boards run Linux...
• Technical Documentation. We try to keep up on documenting the internal goings-on of the compiler and jRate runtime libraries, but things do slip through the cracks, and it would be greatly appreciated to have someone forcing us to stay on our toes and explain that new feature we threw together at 3 A.M. last night!
• User Documentation. jRate changes rapidly, and sometimes yesterday's documentation telling people how to get things up & running is already out-of-date and broken! It would be invaluable to us to have someone that knows what documentation exists and knows what is affected in the next jRate release, so it can be properly updated.
• Web Updates. We like to write compilers, not web pages. If you would like to keep the jRate web site updated with all the latest information about jRate, that would be awesome! A lot of the busy work has already been automated (listing the latest available downloads and API documentation, integration with the SourceForge.net jRate project news feed, etc.), so you can focus on more interesting enhancements.
• Translation. Output from the jRate runtime is in English, as is the jRate documentation. (However, since jRate is based on gcc/gcj, the compiler's output is already translated into the languages that GCC supports.) If you are interested in helping to translate jRate into other languages, please let us know.

The jRate project was, and is, developed by volunteers and students. If you have some extra cash and would like to contribute to a good cause (like keeping jRate Headquarters stocked with pizza and our computer hardware up-to-date), please consider donating to the jRate project or to its individual developers. You can do so from the jRate project page on SourceForge, or from the jRate project members list. A piece of each donation goes to SourceForge. (See the SourceForge donation system documentation for details.) Thanks a lot!

jRate has been hosted by SourceForge.net since December of 2004. SourceForge is an excellent resource for open-source projects and they do a terrific service to the computing community. SourceForge offers its services free-of-charge, but they do accept donations---and also subscriptions, which get you additional features. And I'm not just saying all this because they forced me too. They really are swell and stuff.

Thanks for considering a contribution to jRate! Even if you don't have a lot of time or don't know how you can contribute, please let us know you're interested and we can work something out.