Dom King

One key difference is:
Eclipse usually uses its own Java compiler (from IBM/Eclipse) while
your Ant tool for compiling tool is usually configured to use the JDK's compiler.

It's quite possible, even very likely, that the class bytecode for both versions is slightly different. This may contribute to slightly different runtime characteristics or performance, even exposing different bugs, such as race conditions.

NewJNI, the natural C++ interface to JNI. It's included free with NewJ for C++. There's full source code, samples, and wizards for Visual C++ 7.1 (VS .NET 2003). Ideally, you just want Java wrappers for your C++ objects. It's not that turnkey, but it's more C++ friendly than using JNI by itself.

http://www.pure-native.com/newj.html

It might be easier to use JNI from C/C++ to take advantage of an installed JRE's support for Java RMI.

If you decide to try JNI from C++, take a look at NewJNI, the natural C++ interface to Java. NewJNI is included free with NewJ for C++.

http://www.pure-native.com/newj.html

If you need to call existing C++ code using JNI, take a look at NewJNI, the natural C++ interface to Java. NewJNI is included free with NewJ for C++.

http://www.pure-native.com/newj.html

Things to consider:
- Full source code for NewJNI libraries is included, which can help you learn JNI.
- NewJNI is only implemented for Windows at this time, although the source code is overall very portable C++ and JNI.

If you decide to wrap C++ using JNI, take a look at NewJNI, the natural C++ interface to Java. NewJNI is included free with NewJ for C++.

http://www.pure-native.com/newj.html

Regarding point 2, yes, JNI replaces JRI.

Actually, NewJ Library for C++ from PureNative Software supports implementing Java applets in C++. It supports two different approaches. Choose the one that best meets your requirements.

(1) If you need to run the applet in a Java PlugIn-enabled Internet browser, such as Internet Explorer or Mozilla, you can use NewJNI to extend the JRE's implementation of java.applet.Applet. You'll probably need to grant your Java PlugIn permission to call native methods from your Java applets.

(2) If you would be able to run the applet in a special-purpose Applet Viewer instead of an Internet browser, you can use NewJ Desktop's 100% native implementation of java::applet::Applet. In this case, you can use all your C++ code as is without the considerations and complexities of JNI.

NewJ Library for C++
http://www.pure-native.com

The answer really depends on your requirements. Do you want to use traditional Standard C Library functions like fopen()? new-style C++ I/O classes and templates? the native Win32 API functions for file I/O? Or, are you free to choose your own library?

If you're free to choose your own library, the closest equivalent for Java's InputStream is provided by NewJ Library for C++. With NewJ, if you want a 100% native C++ equivalent the answer is ::java::io::InputStream. On the other hand, if you need to interoperate with and read from the JRE-created object instance of InputStream, the answer is ::newjni::java::io::InputStream. It's that simple.

NewJ Library is available from http://www.pure-native.com/newj.html

If you need to use the other aforementioned libraries, you might want to see the following two books:
C++ For Java Programmers
C# for Java Programmers (Microsoft Press)

You shouldn't need to resort to COM to "do some tasks on the OS level with Windows 2003 server. For example, creating a user and setting permissions."

This is core Windows OS functionality and it would be easier to accomplish using the Win32 API directly instead of COM.

An simpler and more efficient solution than the overhead of a Java-COM bridge would be to implement one or more native methods using JNI and the Win32 API that do your OS-level tasks, such as "creating a user and setting permissions."

Even if the implementation of the native method itself needed to use COM, that could still be accomplished from the Win32 side of the native method.

Here are the URLs again without the trailing periods:

http://www.pure-native.com/download/index.html#community_tools

http://www.pure-native.com/download/JNIWizards-0_1-vc71-install.zip

Yes, the installer should work for Visual C++ 7.1. Everything sounds right on your side. BTW, which version of Visual C++ 7.1 do you have? Standard? Professional? Enterprise Architect?

We would be pleased to support you (and other developers) directly through our support email account for pure-native.com. Or, you may want to bypass the installer entirely and just copy the wizard files from a zip archive. The zip archive may be downloaded at http://www.pure-native.com/download/JNIWizards-0_1-vc71-install.zip.

We suggest extracting the zip to a separate directory, such as "temp", and then copying the extracted directories and files to
the appropriate location on your system, which by default is "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7".
We hope that everything will now work on your system.

Check out the free JNI DLL Wizard for Visual Studio .NET 2003 available at
http://www.pure-native.com/download/index.html#community_tools.

If you need support for Visual Studio .NET 2002, please let us know and we can add it.

Enjoy!

If you can use Visual C++ 7.1 instead, there's a JNI DLL wizard for it available here:
Download: http://www.pure-native.com/download
Documentation: http://www.pure-native.com/download/JNIWizards-readme.html

If there's enough interest, we would consider providing it for Visual C++ 6 too.

Darrin,

Are you still pursuing an answer on this? Hope so...

Your best approach might be to host your Java class inside the MFC app. This way MFC could enforce modality when you call DoModal() on your dialog. Here are three ways to do this:

(1) You could use the Invocation API. The Invocation API on Win32 also supports interoperability between native windows/GDI and Java AWT. I'm not sure if this approach will meet all of your goals without knowing more about your app.

(2) You could possibly host the Java controls inside the MFC dialog using Java/ActiveX bridging technology from Sun or another vendor.

(3) Change you MFC Dialog to an HtmlDialog, make an Applet-derived class for your Java application, and host your Java applet in the HTML layout for the dialog using Sun's technology for hosting Java inside Internet Explorer. You may need to grant the applet greater security permissions if need be too.

If these approaches don't work, instead of rewriting everything in C++, you may want to take a look at NewJ Library. It'll let you use the Java API naturally inside your C++/MFC app.

NewJ info: http://www.pure-native.com/newj.html

It does not appear that there is any real and complete Java-to-.EXE tool available yet for Windows. Either the tools make a "fake" .EXE that just launches (or installs) the JRE along with your application (BTW, this is basically the same approach as VB or VB.NET's Make .EXE feature), or the tool compiles it to 100% native code but still requires the JRE for the classes you really need, like AWT, Swing, or almost anything new. It seems that practically all Java tool vendors and Sun are convinced that option 1 satisfies/pacifies most developers/users, and that option 2 does not have a market that justifies the tremendous investment in both native compiler and independent library development. Curious, what do you think of the practicality/viability of option 2?

If you're waiting for option 2, you may want to consider NewJ Library in the meantime. It's not (yet) a turnkey solution, but it does allow you to use the core Java API in 100% native C++ apps without requiring any JRE. (Yes, that was a plug.)

NewJ info: http://www.pure-native.com/newj.html