[Gambas-devel] Re: Using GAMBAS for running Visual Basic projects

[Rob]

On Friday 04 March 2005 18:44, Richard Stallman wrote:
> By the way, how come you're using a special byte code for
> GAMBAS? Would it work to use Java byte codes?  I think that
> would be a lot more convenient for the users, not to need a
> special byte code interpreter.  In addition, it would be less
> work for you, since you would not have to maintain the
> bytecode interpreter.  Does this idea make sense?

Here are some of Benoit's responses to this question in the past:

http://www.binara.com/gambas-wiki/bin/view/Gambas/WebSiteFAQ#Will_Gamb
as_be_compatible_with_J

Shortened: http://xrl.us/fcfi

I can't speak for Benoit (I haven't submitted any patches against
the interpreter though I've referred to the source when developing
components), but I can think of several other reasons not to target
Java bytecode.

There are two Java bytecode scenarios I can envision: one where we 
target "any JVM" and one where we target a Free JVM like Kaffe or gij.

Any JVM (which, practically speaking, means the Sun JVM):

1. We are at the mercy of the proprietary JVM developers'
implementations. If J2SE 6.0 comes out and breaks Gambas, we are 
basically screwed once it's widely adopted, especially without the 
ability to debug it. I think the support headaches this would cause 
would far outweigh maintaining the existing bytecode interpreter, 
which is currently quite simple compared to Java.

2. The Gambas interpreter is only 160K on my machine. It's all the 
components that take up space and must be present on any machine 
running Gambas applications. All together (plus a bunch of 
documentation) they are around 10MB. Sun's Java, which is the 
mostlikely thing users will download when they hear they need Java, 
is around 25MB. Most Free GNU/Linux distributions do not ship Java,
and I'm only aware of a few partially-proprietary ones that install 
it by default, so I think the special-interpreter argument is 
something of a red herring. In fact, the way package management works 
on modern distributions, it's actually harder to distribute packages 
that require Java: since Java is non-Free, it's most often a separate 
download or installation.

3. All the Gambas components would have to be reimplemented from 
scratch using JNI, necessitating basically a restart of the entire 
project. I don't even know if it's possible to write GPL or LGPL code 
against JNI.

4. If we toss the whole Gambas component idea and use other people's 
Java bindings, we are at the mercy of their development cycle as well 
as the JVM's. This isn't too much of an issue at present for the 
major ones like Qt and Gtk, but it has been in the past and may very 
well be in the future (c.f. the Perl Qt bindings, which went
unmaintained for almost 3 years.) This would also be a total 
nightmare to document and, while providing a lot of new functionality 
to Gambas programmers, would reduce Gambas to being a glorified 
alternative Java syntax.

Single Free JVM (Kaffe, gij, etc.):

1. Defeats some of the purpose of targeting Java bytecode, since it 
would require one particular JVM.

2. Still requires the user to install a special interpreter (or JIT 
compiler, whichever), except now it's Java-based and not included 
with Gambas. Most desktop users of Java do not have a Free JVM 
installed, since GNU Classpath is not yet sufficient to run most Java 
desktop applications, even Free ones. (The situation is better than 
in point 2 above, though, since kaffe and gij are quite small and 
since they're both Free, there are usually packages available.)

3. Points 3 and 4 above still apply. It could be possible to link 
Gambas components directly against kaffe or gij, but this kind of 
goes against the whole Java philosophy as I understand it.

4. Since kaffe and gij are both developed rather slowly, Gambas 
developers would likely end up doing more JVM work than work on 
improving Gambas. This negates the advantage of not having to 
maintain the bytecode interpreter anymore.

Nonetheless, I acknowledge the advantages of targeting an existing 
well-known, well-documented bytecode. I still hope someone will look 
at targeting Parrot if and when Perl 6 ever matures, since there will 
be only one implementation, it will be free software, and it will be 
installed on basically every GNU/Linux system by default as perl is 
now. The "being at the mercy of the bindings' development cycle" 
issue would then be the only real concern. Well, that and Benoit's 
comfort level, because Gambas is his baby and looking at its current 
state, he must be doing something right.

I wonder if a better idea isn't to develop a cross-compiler that 
converts Gambas bytecode into something gcc can make a native 
executable out of (maybe Java bytecode even fits this bill, I don't 
know.) The interpreter could be kept around to facilitate debugging 
in the Gambas IDE, but programs could be distributed without an 
interpreter (perhaps we could even statically link components against 
executables produced that way.) That would be way beyond my skill 
level, but it seems to me such a thing should be possible.

Rob Kudla