GCJ adoption and improving our "PR"

Wed Apr 14 14:43:00 GMT 2004

Erik Poupaert wrote:
>So, why not focus on the niches where GCJ could become successful, if not,
>dominant ...
>>
Right - thinking of GCJ as simply a poor imitation of the JRE, as RMS 
apparently does, is definitely the wrong approach. The appeal of GCJ, 
for me, has always been that it does things differently - and in many 
ways, better.
GCJ has unique benefits that should be emphasised - like:
- It allows you to write applications in Java that behave, look, and 
feel just like any other "native" application.
- It allows you (hopefully more easily in the future) to build small 
footprint, efficient static java binaries eg: for embedded systems.
- It significantly reduces startup cost of Java applications, and 
potentially improves memory footprint and performance. Performance is 
also more predictable.
- It permits much easier, high-performance integration of Java code with 
C++.
However, I also believe that in order for random Java hackers to see and 
understand these benefits we must work to "smooth the transition path" 
for those coming from the traditional JRE development environment. To me 
this means that gcj must become more robust and easier to use in terms 
of taking existing applications and getting them up and running quickly. 
Java developers don't want to spend hours writing makefiles, figuring 
out dependencies, learning how shared libraries work, etc, in order to 
compile some complex application, just to find out if it works on GCJ. 
The combination of the BC-ABI, a smarter compiler, and better 
documentation will improve this situation. We should also be looking 
towards writing, say, a GCJ plugin for eclipse, so that "gcj native 
binary" just becomes another deployment target for your eclipse project.
And then there is the "public relations" issue. From my perspective 
there is definitely far more going on in the GCJ/Classpath world today 
than there was, say, 2 - 3 years ago. Adoption and development work has 
undoubtably accelerated. GCJ developers and users know this, I think, 
but apparently there is a perception in the wider community that things 
are somewhat stagnant. Our website doesn't help this perception: updates 
are infrequent and the content is somewhat out of date.
So, I propose that we work to improve the website so that it includes 
wiki-style dynamically updatable content, especially for things like 
news items, development status, FAQ entries, etc.
I also think we need to improve our documentation so that it has more 
"getting started" content in addition to the reference stuff - eg: a 
simple walk-through on how to compile an application with GCJ. Yes, this 
stuff exists already, but people have to dig around for it. Having the 
documentation in one easily accessible place would be a big step forward.
Regards
Bryce