From: Jim Peters (jim_at_uazu.net)
Date: 2002-03-10 10:31:17
John Morrison wrote:
> Jim have a read through the archives, what you are proposing is the
> basic idea I proposed 2 months ago. Doug and I had a rather lengthy
> discussion about Java it's advantages and shortcomings!
Yes, I was there, and listening, and agreeing with most of what was
said. The only thing missing was a solution. In fact if it was two
months ago, Adam Megacz was still in the middle of the MinGW port of
GCJ at that time, so GCJ wouldn't have been usable even if we'd
looked.
> The major disadvantage is SPEED! As we are creating a REAL time
> system speed is of the essence!
GCJ deals with most of the speed question by pre-compiling to machine
code, just like C++. Also, I'm talking about putting all the critical
real-time stuff in another thread using C/C++ to avoid GC problems.
See here for GCJ details:
http://www.gnu.org/software/gcc/java/
> Doug has convinced me that C++ is the BEST for the platform (though
> I still have a few queries) and as he is the EXPERT on JAVA I'd
> suggest we ask him what he thinks of the idea first.
Perhaps, rather than posting a reseached but untested idea to the
list, trying to get some kind of group approval, I should just do it
anyway and prove that it is viable in that way. After all, how can
anyone approve something when there is no hard proof yet ?
Maybe I'm somehow just trying to set up a challenging situation for
myself as an incentive to get it done.
> One major drawback is no AWT support yet, which means a lot of your
> display routines will have to be written in C/C++ as it can't be
> written in native Java!
They can be written in native Java so long as we have a few interface
routines to access SDL or some SDL-based graphics primitives code.
But I agree, there is still the whole question of what to use for the
GUI that is unanswered. If people think this is a good reason to
stick with C++, or use another platform entirely, I can accept that.
I was hoping that people might be able to avoid the temptation of
seeing this as Java 1.3 *minus* two version levels, and *minus* the
AWT/Swing/etc. I was hoping you could see it as C + FFTW + libSDL
*plus* a nice well-known OO language to control the whole thing. This
is really what GCJ gives us -- it integrates Java into the language
family of C and C++, and lets us pull different solutions together on
a more equal basis.
I know that the resulting combination is completely non-portable away
from GCC, though. Is this a good reason to use C++ instead ? For
portability across compilers ? Taking the SDL route, we are already
tied to SDL's portability, though.
> Well My 2 cents worth
Really I'm trying to connect what I am happy with to what you and
others are happy with, to bridge the gap.
There is a risk that it will all get too much tied to the types of
solutions that I prefer, though. I know Joerg is using another
compiler on Win32. Maybe he has good reasons for that choice.
GCJ is the best packaged solution I've found to move forwards from
here, but only based on my own preferences and my own understanding of
the situation. It is close enough to the hardware to make me happy,
and it gives you, me and Doug (at least) a familiar OO language to
work in, which will surely help things along.
But the whole thing is only worth it if the extra efficiency in
development later on pays for the time it takes to get the tools in
place and working.
There is another approach -- I could do the same thing all the other
way around:
- First of all get BWView built and working using GCJ on Linux
- Cross-compile BWView to MinGW using a GCJ 3.1 cross-compiler from
Linux, so we have a Win32 binary release (which is what Adam Megacz
has used for his XWT ActiveX app, and which he has posted
instructions for)
- Get GCJ 3.1 built and running on Win32 last (the untested bit)
But that way there is no guarantee that we have a working GCJ for
Windows people to use until much later.
Indecision ...
Jim
P.S. By the way, I'm really interested in some of the stuff Adam
Megacz is doing, because in his XWT thing, he has user-interface code
coded in Java and compiled with GCJ, which is interpreting XML source
on the fly (a bit like HTML and tables, he says), and with an
ECMAScript (JavaScript) interpreter built in. He has not yet released
source on his site yet though, but he says it will all be under the
GPL:
Maybe we can borrow some of that code later on ... ?
-- 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