From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-10 12:15:58
> 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.
Yep it looks GREAT!
> See here for GCJ details:
>
> http://www.gnu.org/software/gcc/java/
Yep had a good read this afternoon!
> > 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.
It'd be perfect if AWT was there as a configuration screen could be made of
panels created by the objects we create. :-)
Don't have any idea how we can do it in C++
> 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 did :-) and it's what I'm been hoping for QUITE some time!!!
> 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.
What does GCC NOT run on??? Linux and Windows are our only platforms (At the
moment!)
> > 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.
Great idea that was behind my original idea too!!!!
> 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.
Defiantly!
> 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.
It will!
> 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.
So GCJ doesn't run on Windows.............. :-(
I missed that :-( is a MAJOR drawback!!!!!!
I manly use Windows for development work
> 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:
>
> http://www.xwt.org/
>
> Maybe we can borrow some of that code later on ... ?
Defiantly looks interesting!
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:40 BST