RE: Running java from CL was: RE: Java for RPG Programmers, 2nd edition still useful ?

Does CommandGate allow calls to feed response data back to the caller ?

it's running on a prestarted JVM ans as it running in a Multithreaded environment, you can't use System.out for this.

Your command gate component looks interesting, but it adds another layer to worry about because it requires Tomcat or some other app server container, correct ?

No, it doesn't need Tomcat. It's using its own server programm (a NEP), but this is rocksolid, it's the base layer of ArdGate which is running in production since its beginning without any problems.

My goal is to be able to create CL commands that don't necessarily require RPG, but simply call a simple fall thru Java program to do some action such as process a PDF with iText, Read/Write XML, etc

this was one of the starting points of CommandGate and this could be done without any programming, there are OpenSource (Java) solutions out there providing Java main programms, which don't need parms back, just a call to a Java main, providing the name of an input file and the name of an output file.

and allow parameters to be sent back from the Java CPP to the command so that the CL commands are embeddable in a standard CL job stream and can return parms via the CL command wrapper.

this could be don via AppServer4RPG. This base layer is extendable by a rather simple interface and you could define your in and out parameters as you need. ArdGate is implemented this way and it has to implement rather crude parameter structure going to and back.

An interesting by-product from my testing and using JT400 was the simple ability to run a job on a remote system and bring back response data without any special remote system setup. JT400 rocks for inter-system IBMi
communications and can now be used to easily perform inter-system program calls without a lot of work.

the problem is arising, when you are starting multiple JVMS (worst case: one for every call). This is rather sloon server machines (as AS/400, but not only) and doesn't scale well.

The secondary goal is to possibly move some RPG developers forward who may have been previously afraid to touch Java. As you know it's not that hard to use. It just gets roughed up a lot :)

That's not my experience; if they don't forget many things, they've learned for RPG, they are writing RPG logic in Java,, resulting in ugly code, which is hard to maintain (have a look to jt400, here you could see such code.

In today's world with the faster JVMs available and installed natively, there's no reason not to consider Java to build command processing programs that use the JVM directly.

On AS/400 CPU is rather expensive and the startup process of a JVM is much slower, than on other boxes. Running Java in a server manner: one prestarted JVM serves multiple clients in a multithreaded environment outperforms the direct call variants by far. Creating PDF from XHTML (without any programming needed) the runtime was cutdown from 10 to 20 seconds to subsecond (comparable to windows boxes). Just replacing RUNJVA with RUNJAVARUN this is happening and no classpath fiddling needed, just throw your needed jars to the lib directory of AppServer4RPG.

With my approach an RPG developer will hopefully be able to be writing Java based fully callable/embeddable CL commands within a few hours without any system setup beyond building a little CL program and placing a small Java
class
in the appropriate IFS folder.

With a little extend to AppServer4RPG the interface could be extended for giving back parms as needed. The programmer would just write a Java class with a static method, "called" from RPG, or even direct from CL. This extend could be done easily and with a little bit of sponsoring I would make it open source (CommandGate was a similar joint venture.

Dieter

PS: if the discussion is getting to specific, feel free to contact me direct by eMail.