Re: FAQ update

[Bradley Schatz <bradley dot schatz at netali dot com>]

Per Bothner wrote:

> 2.2 Does GCJ support using straight C native methods ala JNI? CNI looks kind of hard to use.
>
> "The use of CNI reflects the projects focus on simple interfacing of
> legacy C++ in embedded environments."
>
> That is not true.  We use CNI because we think it is a better solution,
> especially for a Java implementation that is based on the idea that
> Java is just another programming language that can be implemented
> using standard compilation techniques.  Given that, and the idea
> that languages implemented using Gcc should be compatible where
> it makes sense, it follows that the Java calling convention should
> be as similar as practical to that used for other languages,
> especially C++, since we can think of Java as a subset of C++.
> CNI is just a set of helper functions and conventions built on
> the idea that C++ and Java have the *same* calling convention
> and object layout;  they are binary compatible.  (This is a
> simplification, but close enough.)
>

I have woven this explanation into a new question, "Why does GCJ use CNI?"

>
> "that call the corresponding JI methods"
>
> s/JI/JNI/
>
> "(3) You could in primciple write C++ code that implement"
>
> s/primciple/principle/
> s/implement/implements/
>

Fixed. Concisely communicated.

>
> "(4) In any case, a working JNI version would be very helpful, because it
> provides a specifiction/prototype"
>
> Not relevant to the FAQ.  It was in response to the question of whether
> a JNI version of some library (such awt) is useful for libgcj.  My
> point is that a working library, if ok from a licensing point of view,
> is very useful even if it uses JNI, since it is much simpler to convert
> the JNI stuff to CNI than to start from scratch.
>
> This is relevant to question 2.3.
>

I have dropped out this piece.

>
> 2.4 How about support for Swing?
>
> One possibility worth considering is developing Swing components
> in conjunction with AWT.  We can implement JTextArea and TextArea
> at the same time.  We could also implement both on top of (say)
> some Gtk widget;  we don't necessarily *have* to go the "peerless"
> route.  Instead, we can base the "plugable look-and-feel" on the
> "themebility" of (say) Gtk.
>
> A bigger potential issue is Swing's separation between "model"
> (e.g. Document) and "view" (e.g. JTextPane).  It may be
> difficult to make use of the functionality of an existing
> toolkit such as Gtk unless we can use Gtk widgets with
> separate "model" objects.
>

Added to the SWING section.


Bradley