From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-10 00:26:43
I took a break from the list today in order to try and have a think
and make some progress. I'm part way through giving BWView an OO
rejig, and it is not pleasant in C, and I'm getting bogged down. I've
been having a look around at other OO tools we could use, like
Objective-C or Java. I personally don't get on with C++ very well,
although I know Andreas appears pro-C++. I think Doug has expressed
some misgivings about C++ also.
Right now I'm thinking of Java, not for higher-level features like AWT
or Java 1.2 libraries, but just as a language to make coding OO stuff
more pleasant, with all the heavy and critical stuff still done in C
or C++ (like the FFTW code, heavy analysis, SDL interface, serial
input/output, whatever).
To me the big problem with using Java for anything is the garbage
collection. However, if we implement all the critical stuff
(real-time audio generation and output, data input, making LEDs flash,
etc) in C in a separate thread that the garbage collector doesn't know
about, then the front-end can block for a garbage collect without
stopping anything critical. If we can live with occasional momentary
front-end pauses, Java looks usable. If the GC turns out to be
*really* well implemented, we might never even notice.
Given the skills we have on the group, Java looks more attractive to
me than Objective-C or C++. John is very pro-Java, Doug is very
nearly a Java/Linux cyborg, I've done much more work in Java than C++.
Java is more friendly when presented with newbie code than C++.
At present, MinGW only supports C and C++ (it is based on GCC 2.95).
I've used Toba before for Java compilation (via C), but it is quite
old now and no longer updated. Also, to get it working on Win32 using
pure open-source tools means something like Toba + Boehm-GC + GNU
Classpath + Jikes java compiler. This is a very big and very untested
combination.
I'm very attracted to GCJ, which is the GNU compiler for Java, which
incorporates much of the Java 1.1 libraries (except for AWT)
reimplemented as libjava. It is built into GCC from version 3.0
onwards. However, reading the MinGW list, it seems that GCC 3.0 is
not recommended yet, and they are waiting for 3.1 to stabilise.
GCJ is very very nice -- it does everything we need and much much
more. It can compile from both .java and .class files. You can write
C++ code to interface to it very naturally using all the normal Java
names, basically using '::' instead of '.'. You can catch Java
exceptions with C++ 'catch', you can create garbage collected Java
objects with C++ 'new', and so on, and so on.
I also looked at ORP, which is an open-source optimising JIT Java VM
for Windows and Linux written by Intel. It supports multiple garbage
collection algorithms. I was hoping I could find a Java->C compiler
or VM that used reference counting, or some other GC that never blocks
for very long, so we could use it for coding all parts of the app,
including the sound output, but I have not found anything that does
that. (Toba could perhaps be adapted to ref-counting, but that would
take some significant time and head-scratching ... and before you
mention it, yes, I do know about the problem of cyclic references for
ref-counting GC).
So, here is my crazy idea. I try to get enough of GCJ built and
working on MinGW so that we can code easily in Java for OO stuff, and
C/C++ for low-level fast stuff. We interface with SDL for fast
portable graphics, and FFTW for fast transforms.
This may be pushing at the (b)leading edge a bit. I may actually end
up contributing to GCC if I am really unlucky. However, from scanning
the MinGW list, it appears that Adam Megacz has done all the work to
get GCJ ported to MinGW, to use in his XWT project (which is very
interesting -- see <http://www.xwt.org/>). Although a 3.1 GCC binary
release for MinGW is not yet available, it must be pretty close. I
think this should be do-able, by building from GCC CVS, perhaps with
some help from the MinGW people or Adam Megacz if necessary. (I have
E-mailed Adam Megacz just now to see if his patches are in CVS yet).
I know we could probably go for other Java solutions, but I'm working
with what I know and trust, and with what I feel is within my
skill-set to achieve. It also means we would be working on identical
tools on Win32 and Linux, i.e. we would be seeing identical bugs.
People who have a Java IDE they prefer can probably use that, and just
run a .BAT or MSYS 'bash' script to do the final .EXE build using gcj.
I also like GCJ because there is no feeling of a 'fluff' layer as
there is in some other Java implementations. Java really is mapped
almost directly to C++ (or at least to its internal representation in
the compiler) and from there straight to machine code. Also GCJ is
very future-proof. It is not going to go away.
I would also like to get a round-up of what kinds of skills we have
available on the software side. The aim of choosing a development
platform would be to allow all the people with available skills and
time to hack the code easily. There seems to be a lot of emphasis on
OO techniques and structuring in our 'design' department, with Java
preferred by two, at least.
This is what I make of our software team skills at present. Please
add to or correct my assessment if I have got it wrong:
Doug: Java, OO design
John: Java, OO design
Dave: C++, OO design
Jim-P: C, Java, SDL
Jim-M: C
Andreas: C++ (busy with hardware, though)
Joerg: SDL/C/C++ ? (busy with hardware, though)
At the moment, [Doug,John,Dave] seem to be oriented towards the design
side of the project. Jim-P is oriented towards coding. Jim-M would
like to be able to make tweaks. Joerg seems to have some SDL
experience (from previously posted screenshots). Andreas has
expressed C++ leanings.
For non-Java programmers, like Jim-M, let me reassure you that Java is
very friendly to beginners, and if you're just going to make tweaks to
existing code, a knowledge of C is enough to get started.
Also, I'd like to know who is really *serious* about putting some time
and effort into the software. For instance, design people, I would
hope (once we have the tools) that you'd start knocking up classes to
get some ideas tested. People who can't commit so strongly to giving
time and effort, please, you have to accept that your views might not
be represented in the final code. The people doing the work have
final say on what gets done.
Work to do:
- Build FFTW on MinGW (done, but necessary to work around some build
problems)
- Build and test GCJ on MinGW (big unknown, but in principle do-able,
I think (I hope!))
- Convert existing BWView code to interface to GCJ, and/or rewrite in
Java.
- More as we get there ...
As I say, anyone looking in from the outside might think this is a
completely crazy approach -- who ever heard of using Java to control
libSDL and FFTW ? But as I say, this is just my approach based on
what I feel happy with. If someone else has the time and skill to
suggest *and implement* another solution, or to extend this solution,
we can talk about it. Otherwise, you'll get my crazy solution. Okay?
So, any comments or suggestions ? Am I crazy to try to make this leap
towards Java ? Do you want to try to persuade me to use C++ instead ?
Or some other solution (bearing in mind it might be you that has to
implement and support it if it doesn't look do-able for me) ?
I'm going to sync with GCC CVS tonight, and look at trying to build
GCJ on MinGW tomorrow. (In case there are too many problems with GCJ
on MinGW, though, we'll probably have to go to 'plan B', but I have no
idea of what that might be right now.)
Hoping I am not leaning too far forwards with all of this --
Jim
-- Jim Peters (_)/=\~/_(_) jim_at_uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST