FAQ update

Sun Nov 7 21:44:00 GMT 1999

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