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

[Richard Stallman]

This is not my project, so I am not going to try to insist on telling
people how to design it.  Please don't interpret this message as
trying to demand a change.  However, I'd like to respond to the
arguments you've raised.

    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):

The scenario I would first think of is targeting all JVMs, but
focusing on a free one such as GIJ.  

    1. We are at the mercy of the proprietary JVM developers'
    implementations. If J2SE 6.0 comes out and breaks Gambas,

If you use documented interfaces used by many others,
it is hardly likely any Java platform developer would break them.

    4. If we toss the whole Gambas component idea and use other people's 
    Java bindings,

I do not know what the "Gambas component idea" is, but using other
people's bindings for other packages seems to be a very good idea.

		   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.)

When that happens, it is a problem, but you don't have to consider
that your problem.

				      This would also be a total 
    nightmare to document

In some sense, it would not be your problem.  However, if you want to
undertake the extra responsibility to document bindings for GTK and
Qt, it seems to me that your work would provide increased benefits to
the community if the bindings you are documenting are also useful to
others.

			  and, while providing a lot of new functionality 
    to Gambas programmers, would reduce Gambas to being a glorified 
    alternative Java syntax.

Would that be a bad thing?  The usefulness of a project is not measured
by the amount of effort you duplicate.

    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.

Another way of putting it is that the work you do on maintaining
the bytecode interpreter would also benefit lots of Java users.

    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 Gambas parser could be turned into a GCC front end.
GCC could generate Java bytecodes as well as native code.