Ok, for those of you familiar with JNI ... here's a scenario:

I need to write a program in either .NET or Java that does a function foo(). Both platforms are utilized an equal amount, so which the primary program is written om doesn't matter to me. foo() will ultimately create a string that will need to be passed to the other platform on the fly.

Method #1:
- Write foo() in Java
- Write a DLL in .NET with JNIExport to pass the String, load the DLL in Java
- .NET calls foo() by invoking java.exe
- Java calls foo() by package includes

Method #2:
- Write foo() in .NET
- Write a DLL in .NET with JNIExport to pass the String, load the DLL in Java
- .NET calls foo() by package includes
- Java calls foo() by invoking prog.exe

Is either method better/worse than another? OR, is there an entirely different solution for this which doesn't involve JNI? Advice/suggestion appreciated. Thanks.

3/21/2006 3:01:52 PM

Talked with a couple of people ... found an alternate solution to the greater problem at hand. Still curios if anybody has any opinions on the proposed scenario above.

3/21/2006 3:36:05 PM

So many better alternatives than JNI

Perhaps you should investigate why you need different languages/frameworks in the first place.
Once you go to managed code(.NET) you should be isolating what is brought into the CLR as much as possible. JNI doesn't really provide the correct isolation.

This is really more of a general design problem than a technology problem. What you should really consider is maintaining the component-oriented architecture and perhaps extending into COM if you really need to use unmanaged code. Or an ever better solution would be to use SOAP or an alternative web service technology.

3/22/2006 10:39:34 AM

^
Right, the alternative solution avoids JNI altogether ... something I was advocating for in the first place ... but needed to look into anyways.

3/22/2006 11:03:37 AM