Generating C++ files from javah for JNI
Anuj Goswami
The javah utility by default generates a header(.h) file which is
a 'C' function.It is with the extern'C' declaration.
Is it possible to make javah utility generate C++ functions?
The problem is that if the header file declares a functions as a 'C'
function then its implementation cannot be in C++ .for example we
cannot use "cout" or "cin" in our implementation functions.
Any help would be greatly appreciated.
Thanks and Regards,
Anuj Goswami
NOKIA TELECOMMUNICATIONS
Joseph Millar
wrote:
> The javah utility by default generates a header(.h) file which is
> a 'C' function.It is with the extern'C' declaration.
> Is it possible to make javah utility generate C++ functions?
No. The JNI expects to have C-style functions so that it
pushes args on the stack in the correct order.
> The problem is that if the header file declares a functions as a 'C'
> function then its implementation cannot be in C++ .for example we
> cannot use "cout" or "cin" in our implementation functions.
That's not true. There is absolutely nothing preventing
you from putting your native function code in a C++ file
and using standard C++ stuff like cin and cout. All the
prototype says is that when this function is called, the
args on the stack should look a certain way, and that the
generated function name in the executable should not be
name mangled so that JNI can find it.
Almost all my native methods are written in C++ because I
find the JNI API easier to deal with in the C++ style
syntax (ie. env-> instead of (*env)->, and no env first
arg).
--Joe
________________________________________________________________
Joseph A. Millar <jmi...@mediaone.net>
"Very funny, Scotty! Now beam down my clothes!" - James T. Kirk
Hans Wegener
> No. The JNI expects to have C-style functions so that it
> pushes args on the stack in the correct order.
Big surprise for me. I thought it was because C++ name mangling isn't
standardized and a JNI-based library would then not be guaranteed to work with
the JVM? Can you explain a bit in depth?
HW
--
Phone: +41-1-334 66 51
Fax: +41-1-334 50 60
Mail: hans.w...@credit-suisse.ch
Web: http://www.credit-suisse.ch
Roedy Green
<hans.w...@credit-suisse.ch> wrote or quoted :
>Big surprise for me. I thought it was because C++ name mangling isn't
>standardized and a JNI-based library would then not be guaranteed to work with
>the JVM? Can you explain a bit in depth?
The keys requirements would be:
1. a name mangling technique from Java -> C that is standard across
all platforms.
2. a calling convention that both C++ and C can use without change.
3. One you can use direct to assembler (This we don't get. Perhaps if
I upgraded my assembler and linker, or discovered some magic switches
to make it support long names.) Perhaps I am the last assembler
programmer on earth.
4. Ideally it would deal automatically with overloaded methods. I
suspect the current scheme gets in trouble. Javah would have to
change an existing C method name if you ADD an overloaded method. In
return you get shorter names for non-overloaded methods. The javah
scheme at least ensures the signature-adding mangling works the same
on all platforms, and encodes Java package and class.
The Java glossary is at http://mindprod.com
--
Roedy Green, Canadian Mind Products
Ready to take on new telecommute programming contracts.
I will be speaking at the Java Software Summit Conference
http://www.softwaresummit.com in Keystone Colorado Oct 31 .. Nov 4 on
Using Native Classes in Signed Applets and Java gotchas.
-30-
Peter Burka
>
<snip>
>
> 3. One you can use direct to assembler (This we don't get. Perhaps if
> I upgraded my assembler and linker, or discovered some magic switches
> to make it support long names.) Perhaps I am the last assembler
> programmer on earth.
>
What assembler are you using? I've written JNI methods in assembler on
several platforms and haven't had problems with name length limits.
/peter
Stuart D. Gathman
> 3. One you can use direct to assembler (This we don't get. Perhaps if
> I upgraded my assembler and linker, or discovered some magic switches
> to make it support long names.) Perhaps I am the last assembler
> programmer on earth.
Roedy,
The easiest way to write assembler code to interface with a C API is to use a
compiler with inline assembler support. The compiler handles all the calling
convention details.
For Win32, the Borland compiler supports this very elegantly beginning with 3.0.
Borlands inline assembler does not support assembler macros unless you use a switch
to run your assembler after the compiler generates assembler source. However, C
macro and conditional compilation are available for the inline assembler code.
The GNU compiler also has an elegant inline assembler capability which is geared
toward optimally inserting tiny bits of assembler into the C generated code. You
supply dataflow information (i.e. which registers are read/written/trashed) along
with your assembler snippet to support this. This allows the combined C and
assembler code to be fully optimized. The Borland approach, while easier to use,
tends to inhibit optimizations at the C/Assembler boundaries.
--
Stuart D. Gathman <stu...@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Microsoft is the QWERTY of Operating Systems" - SDG
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
(HINT: Find a translation of the "Dies Irae".)
Roedy Green
<stu...@bmsi.com> wrote or quoted :
> The easiest way to write assembler code to interface with a C API is to use a
>compiler with inline assembler support. The compiler handles all the calling
>convention details.
I agree, in my particular case that would be the way to fly, however,
there are some catches:
1. Borland C++ wants you to buy TASM32 to handle the inline assembler.
They tell you this buried very deeply in the fine print. I wasted
hours trying to get it to work, erroneously thinking I must have
inadvertently discarded inline assembler support during the install.
Borland's variant of assembler is quite different from ordinary MASM.
They can't even agree with Microsoft on how to specify the model.
(.model in MS, model in Borland).
2. You don't have the usual tools like macros, segments etc that you
rely on to write anything complex. inline is for fairly short
sequences.
3. Inline assembler is a language all its own, almost undocumented.
You have to figure it out from deductions based on a tiny sampling of
examples.