java dll

[pratibhprakash]

I'm writing a program in c++ that needs to interrogate a DLL that has
a number of functions in it. I have a source code that is written in
java is this possible to convert this code to dll using some tool so
that i can use it in my c++ program?

 

[KiLVaiDeN]

I'm writing a program in c++ that needs to interrogate a DLL that has
a number of functions in it. I have a source code that is written in
java is this possible to convert this code to dll using some tool so
that i can use it in my c++ program?

Hello,

What you need, is either a parser into C++, or a compiler that would
produce a DLL directly accessible from your C++ program.

I'd advice you to take a look at those tools ->
http://dmoz.org/Computers/Programming/Languages/Java/Development_Tools/Translators/Java_to_Other/

You can find there something of interest, specially the Java to CPP
converter, which might really help in your case

K

 

[Chris Smith]

I'm writing a program in c++ that needs to interrogate a DLL that has
a number of functions in it. I have a source code that is written in
java is this possible to convert this code to dll using some tool so
that i can use it in my c++ program?

The only way to proceed that's spec-safe is to use the JNI invocation
API to create an instance of a Java VM, and run the code in that VM.
That's very heavyweight, but it definitely works, even across Java
virtual machines and platforms. Otherwise, there may be a vendor-
specific way to do this. Someone who knows more about Jet than I do
could perhaps take up the question.

Of course, if you have the source code and it's not too large, you might
do a port at the source level.

 

[Luc The Perverse]

I'm writing a program in c++ that needs to interrogate a DLL that has
a number of functions in it. I have a source code that is written in
java is this possible to convert this code to dll using some tool so
that i can use it in my c++ program?

Yes use excelsior.

http://www.excelsior-usa.com/jet.html

Incidentally, there is a certain Canadian who would appreciate it greatly if
you bought the program through the link on his page - and if you don't know
what I'm talking about, then nevermind.

 

[ldv]

The only way to proceed that's spec-safe is to use the JNI invocation
API to create an instance of a Java VM, and run the code in that VM.
That's very heavyweight, but it definitely works, even across Java
virtual machines and platforms. Otherwise, there may be a vendor-
specific way to do this. Someone who knows more about Jet than I do
could perhaps take up the question.

Excelsior JET is certified Java Compatible, so it also supports JNI.
Fetch a trial from http://www.excelsior-usa.com/jetdleval.html, install
it, and look under samples/Invocation to get going.

GCJ (http://gcc.gnu.org/java/) implements its own Java-native interface
called CNI. Here is an excerpt from the GCJ FAQ
(http://gcc.gnu.org/java/faq.html):

----------------------------------------------------
2.2 Does GCJ support using straight C native methods ala JNI?

Yes. libgcj now has experimental support for JNI, in addition to
its native Compiled Native Interface (CNI). gcjh will generate JNI
stubs and headers using the "-jni" option. However, we do prefer CNI:
it is more efficient, easier to write, and (at least potentially)
easier to debug.

2.3 Why does GCJ use CNI?

Per Bothner explains:

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.)
----------------------------------------------------

I would recommend anyone to stick to JNI, though, as it is THE standard
and thus must be supported by all compatible JVMs.

LDV