|
Michael Polutta wrote: > We're investigating (heavily) on the best way to evoke Java methods from RPG. > (I don't mean should we declare the prototypes in RPG and evoke the methods > by name - that much is a given.) Who has been down this road already? What > are the pitfalls? What are the performance areas to concentrate on? > Michael, be sure to read all of the V5R2 version of the "RPG and Java" section of the ILE RPG Programmer's Guide. There are some common pitfalls discussed there that are relevant even if you are using V5R1. Most of the pitfalls are related to the fact that this support uses JNI (Java Native Interface), and there are some inherent problems related to JNI-use in general, independent of the native language or system. Aside from the garbage colllection and memory leak problems that you can read about in the programmer's guide, the main pitfall that I see is that once you have called Java this way once in your job, you can't reliably shut down the JVM and start again. You're stuck with whatever classpath your started with. If some other application sets the classpath and starts the JVM, and you wanted a different classpath for your application, yours might not work. That's not necessarily a show-stopper, but it means that you need some way of getting the classpath set correctly for all JNI-using applications whenever any application starts the JVM. Adding a *SYS level CLASSPATH environment variable might be a good way to do this, so that every job would automatically have it set correctly. By the way, there are relatively few problems related to calling RPG as a native method from Java. In some cases, it might be a good idea to use the JAVA command to start up a Java class with whatever classpath you wanted, and have it call an RPG native method. That RPG native method could then call back to whatever Java it wanted to. Regarding performance: For every call to a Java method, RPG has to make several JNI calls, including a call to "CheckException" after almost every JNI call. If there are character parameters, it has to do ebcdic/ascii translation (possibly back and forth if it's a non-CONST parameter). If there are arrays, it has to create a Java array object and copy the data (possibly back and forth). So, if you have to make several method calls in one section of code, it might be better to write a Java method to do all the Java stuff, and just call that one method from RPG. Think of the Java method as a sort of subprocedure.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.