Andrew,
Another worthwhile book is "Java RMI" by Troy Downing, IDG
Books.
Good luck.
- Chris Sommers
dan wrote:
>
> I concur, in general, about the cryptic errors that occur with JNI coding. I tend
>not to put
> everything within a single function call, but I do follow the KISS principle (Keep
>It Simple,
> Stupid).
>
> May I also suggest the book, "essential JNI: Java Native Interface" (sic on
>capitalization), by
> Rob Gordon. This is an excellent (no, authoritative) book on the subject of JNI.
>It is very
> well written. Following the KISS principle, you'll probably only need to read the
>first 2 or 3
> chapters.
>
> There are other native interfaces available, as well. Netscape's JVM has their own
>native
> interface, developed before JNI was available. However, Netscape has deprecated
>this interface
> in favor of JNI.
>
> Microsoft's JVM uses something called RNI (Runtime Native Interface), and does *not*
>support JNI
> (you can, however, use Sun's Java Plug-In, which encapsulates Sun's JVM inside an
>Active-X
> control). Microsoft will likely never support JNI. This is, in fact, the source of
>Sun's
> accusations against Microsoft for not supplying a JVM that is compliant with the
>Java standard.
> Why does Microsoft do this? WFC, Microsoft's Java interface to MFC, makes extensive
>use of
> native calls (as you might expect). In order to make WFC faster than it would
>otherwise be, RNI
> allows native code to get the address of Java variables directly (which, of course,
>would not
> work if data is moved in memory, as the JNI specification allows). To support JNI,
>Microsoft
> would have to cripple (in terms of speed, anyway) the WFC, something Microsoft is
>not likely to
> do.
>
> We have built a bridge between RNI and JNI for our internal use (we provide Java
>toolkits for
> data visualization). This way, our native code and our Java code remains intact.
>Our bridge
> maps the RNI stubs to call the JNI stubs, and provides the JNI data access functions
>in the
> event that the JNI is not available. However, we do not offer this as a product
>(yet). If
> there is sufficient interest, we could probably be coaxed into developing this into
>an actual
> product. Please e-mail me if you require this functionality.
>
> I hope this helps. Native interfaces have been the source of a lot of headaches for
>Java
> developers. I repeat my earlier advice: KISS.
>
> -dan
> [EMAIL PROTECTED]
>
> Diego Pons wrote:
>
> >
> > I'll try to be less terse this time.
> > First, RMI is a great solution, much simpler to code than say RPC's
> > for developing client/server interfaces. The only complication is that
> > to support legacy systems not written in Java, you will need to create
> > a (non-portable) bridge using JNI (see Dan Kirkpatrick's response to you).
> >
> > JNI allows you to interface with the C language, having thus access to
> > the underlying operating system or application interfaces in C.
> > As D.K. says, in JNI you have to map Java classes to C structures on
> > the output arguments, and C to Java on the input arguments, all the while
> > checking for errors at each step. This is a lot easier to say than to do.
> > Most errors will cause the JVM to dump a (most enigmatic) core.
> >
> > Given this difficulty, I suggest to minimize the number of JNI functions.
> > One way is to create a mega-call in JNI where the parameters are a command
> > and a related argument list as strings, in a way similar to ioctl() calls.
> > A typical API would then be handled in this way:
> >
> > my_jni_call(..., OPEN_CMD, arg, NULL)
> > my_jni_call(..., READ_CMD, arg, argsz)
> > my_jni_call(..., WRITE_CMD, arg, argsz)
> > etc, etc.
> >
> > While this goes against elegancy in design, it will add to the robustness
> > of the product by eliminating error-prone Java<->C mapping code.
> > Unfortunately, this came to me only after writing about 3000 lines of
> > the interface code.
> >
> > I suggest reading "Core Java, Volume II", by Horstmann and Cornell for
> > both RMI and JNI examples and references.
> >
> > --
> > Diego Pons Pharos Consulting LLC
--
