Feb 05
I am 100% behind Cedric on this one.
I get frustrated when Sun is so pious on the whole VM, 100% portable code, thing.
The reality is that we have real work to be done. There are viable situations where I *need access to native code*. Why not allow me a nice way to do this?
There is a LOT of code out there in C++ etc, and not everyone wants to port it to Java. Give us nice intergration paths, and NICER THAN JNI.
We know that great people on the Sun team have created a better way to work with native code (a la .NET).
Let us have it. Let us have the control.
February 7th, 2005 at 1:24 am
I for one do NOT get why JNI is so badly written. I mean, why you can’t just load a library that the Java runtime/JDK can use directly on the platform they are in is beyond me. Why I gotta create .h files and use a horribly bad naming convention in the C code is beyond me! We are just starting to play with JNI and it’s a mess.
February 7th, 2005 at 1:24 am
I for one do NOT get why JNI is so badly written. I mean, why you can’t just load a library that the Java runtime/JDK can use directly on the platform they are in is beyond me. Why I gotta create .h files and use a horribly bad naming convention in the C code is beyond me! We are just starting to play with JNI and it’s a mess.
February 7th, 2005 at 7:15 am
“Why I gotta create .h files and use a horribly bad naming convention in the C code is beyond me!”
I use JNI to wrap the Qt and KDE C++ apis for java bindings. In C++ you have method overloading, and you need the JNI naming convention to map the overloaded methods onto the java api. The .Net P/Invoke api doesn’t have a standard way to define overloaded methods, and that is a problem.
I think the main problem with JNI is the lack of automated code generators. It is far too much work to wrap a C++ library with more than a handful of classes. The Qt/KDE apis have around 1000 classes, and would be impossible to wrap without automating to code generation.
The gcj compiler has an alternative to JNI called ‘CNI’ which is a much more natural interface to C++ code, and is more efficient.
Overloaded methods and unsigned types would be a great help in interfacing with C++ libraries, and ‘religious’ arguments about not including them in java annoy me a bit. That sort of thing is actually useful for integrating with the ‘real world’.
February 7th, 2005 at 7:15 am
“Why I gotta create .h files and use a horribly bad naming convention in the C code is beyond me!”
I use JNI to wrap the Qt and KDE C++ apis for java bindings. In C++ you have method overloading, and you need the JNI naming convention to map the overloaded methods onto the java api. The .Net P/Invoke api doesn’t have a standard way to define overloaded methods, and that is a problem.
I think the main problem with JNI is the lack of automated code generators. It is far too much work to wrap a C++ library with more than a handful of classes. The Qt/KDE apis have around 1000 classes, and would be impossible to wrap without automating to code generation.
The gcj compiler has an alternative to JNI called ‘CNI’ which is a much more natural interface to C++ code, and is more efficient.
Overloaded methods and unsigned types would be a great help in interfacing with C++ libraries, and ‘religious’ arguments about not including them in java annoy me a bit. That sort of thing is actually useful for integrating with the ‘real world’.