JNI/CNI (was Re: CharSequence support)

[Etienne M. Gagnon]

> 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:address@hidden |
| 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:address@hidden |
| 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/ |
+--------------------------------------------------------------------+