> Here's an example issue: if native code is combined then how do you
> throw an exception? ...
I think we should be asking the question: How much native code should
there be in Classpath, in the first place?
My humble opinion on this would be: as little native code as possible,
for many reasons. Here are the most important one, I think:
(1) More native code => more potential for difficult to find bugs. (I
won't restate here the whole Java vs C/C++ argument:-)
(2) More native code makes it harder (and longer) to port Classpath to a
new VM/OS/Processor/etc.
(3) The [Java <=> native] bridge (be it CNI/JNI/whatever) is usually
associated with a high invocation cost due to the many little details
involved (GC requested on another thread, dynamic binding, etc.). These
details might not all be currently implemented in most free JVMs/Java
systems (like gcj), but are important in a fully compliant system.
Keep in mind that we are talking about the core libraries, not about the
various applications that coud be developed around it.
In light of this, native calls, in the core libraries, should be limited
to the strict minimum, mainly:
(1) interfacing with the undelying OS, like the file system (java.io),
the graphical system (java.awt/peer), the network interface (java.net).
And, again, this should be done with a minimalist approach: do as much
as you can in Java, and simply implement one or two SHORT methods natively.
(2) implementing a few critical methods that would greatly benefit in
performance from being implemented in the native language. One might
think here of some graphical bit processing operations that are best
implemented in assebly langage or C to attain the highet performance
(without array bounds check).
If we limit the native code to the above 2 things, in the core
libraries, and we want the native code to be as efficient as possible, I
see no reasons for this code not to be written in plain C (and JNI:).
Why? Because C is fast (with no hidden performance costs, like C++) and
portable. As this code is supposed to be short, there's no need for the
application framework support of C++ (anyway, if you want to write
application size modules, you should write them in Java!).
This minimalist approach is proned even within the leading Sun and IBM
JVM development teams, as far as I understood from talking with some of
their VM specialists at various conferences.
I know that GCJ has this very "neat" CNI interface. I'm all for a neat
"application" native interface for GCJ users. But we should not confuse
application developers using a mostly static Java native compiler (GCJ),
with core class library developers developing (according to the
Classpath web page) a small VM independent native layer for the libraries.
Have fun!
Etienne
--
+--------------------------------------------------------------------+
| �tienne M. Gagnon mailto:[EMAIL PROTECTED] |
| Professeur adjoint T�l�phone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930 T�l�copieur: (514) 987-8477 |
| D�partement d'informatique, UQ�M http://www.info.uqam.ca/ |
| Auteur de SableVM http://www.sablevm.org/ |
| et de SableCC http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| Etienne M. Gagnon mailto:[EMAIL PROTECTED] |
| Assistant Professor Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930 Fax: (514) 987-8477 |
| Department of Computer Science, UQAM http://www.info.uqam.ca/ |
| Author of SableVM http://www.sablevm.org/ |
| and SableCC http://www.sablecc.org/ |
+--------------------------------------------------------------------+
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
