× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.