You're right.
If we're doing pure performance comparison the single JVM wins every time, but now you have different programming considerations like an app server or Java embedded in something like RPG which has the single JVM limitation (which may be acceptable until you start creating super-large POI spreadsheets and crashing the JVM).
Using a simple Java class and even wrapping CL around it allows you to have utility programs that use a best of breed approach to consuming Java functionality from a CL command and actually exchanging input and return parms as well. Often this extended Java functionality is very difficult or impossible to create in an RPG application and often Java classes are not easy to map so RPG can call them either, which is why I just use the Java classes instead of trying to wrap it in with RPG and try to debug the mappings.
Experience level will probably dictate which method a developer may choose if they are not comfy learning some Java. I personally think every developer worth their salt should be learning a little Java and even some PHP, Python or .Net so they are well rounded. However that often takes personal time which many are not willing to invest.
When I think about the use case for the CL commands above, here's some potential criteria:
If the command or Java program is not being called every half-second or more in a transaction processing program or a high-volume production engine like our iForms software, 1-5 seconds per call may be acceptable for the simplicity you can gain.
I always think of the term "perceived performance" which we always talked about when creating subfiles back in the day. If the users think it's fast then it is. If they think it's slow then it is 😊
Sometimes 1-5 seconds per call for a CL command is acceptable performance and sometimes it's not depending on the use case.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
------------------------------
message: 2
date: Tue, 23 Jan 2018 11:34:14 +1300
from: Evan Harris <auctionitis@xxxxxxxxx>
subject: Re: Java extensions directory vs Excel generation
Hi Richard
I am not trying to argue the point here, but this is not a case of "our experiences apparently differ".
Your approach *will* start multiple JVMs which can be a comparatively expensive approach but solves the issue of needing different class paths for different functions.
Whether that expense is acceptable will vary depending on the circumstances of each business.
I am not dismissing your approach, I am just pointing out the additional overhead is not related to "my environmental", it's a specific side-effect of your suggestion.
On Tue, Jan 23, 2018 at 10:28 AM, Richard Schoen < Richard.Schoen@xxxxxxxxxxxxxxx> wrote:
It's all about appropriate use and appropriate JVM choice. (32-bit is
my favorite culprit.)
Also kicking off hundreds or thousands of Java commands at once, might
cause issues.
Controlling them in a handful of batch job threads not so bad.
Our experiences apparently differ, so just keep doing what works for
you in your environment.
Regards,
Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com
midrange.com
