FAQ update
Per Bothner
per@bothner.com
Thu Nov 4 18:48:00 GMT 1999
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.)
"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/
"(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.
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.
More later.
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/
More information about the Java
mailing list