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

The best thing is it takes out the odd nature of trying to map out calls to Java types andmethods in an RPG program and loading only a single copy of the JVM in an RPG app. We had some programming we had done this was that fell
apart at V7R1 so we removed RPG from the Java calling equation because it was not easily debuggable.

this sort of "embedded Java" in RPG is hard to maintain and it's near to impossible to controll the settings of the JVM, mostly ending up in making all settings global, hoping never coming into incompatibility.

I agree with your point on performance if I'm running thousands of these types of calls at a time, but most people aren't. If they are a pre-start approach or NEP app may be warranted as you suggested.

This was the starting point for writing AppServer4RPG. It's a generic Java NEP sitting on a DataQ, waiting for entries. If an entry (consisting of a type and a RPG Datastructure) comes in, it's passed to an EventHandler (it's an Inetrface with a method performWork). AppServer4RPG provides some sessionhandling and gives every event a thread of its own.
To use this, you would only write an EventHandler and registering it to a config file. In my approach all type conversions between Java and RPG is done in the EventHandler. The native (RPG, CL or whatever) simply calls a procedure fireEventP passing in the type of the event and some DS waiting for the responsedata (a DS). Writing an EventHandler is as easy as writing a Java main and it's running in a prestarted JVM out of the box, without any additional line of code. There is a presentation form the european common conference available http://de.slideshare.net/comeur/app-server4rpg-english .

Also writing NEPS like you are describing would be pretty easy because the Java class just has to simply loop until some defined condition occurs. I'm guessing that's probably similar to how ArdGate works as you are describing it.

ArdGate and CommandGate are only 2 EventHandlers running under AppServer4RPG. All looping, DataQ handling, packaging data, threading, session handling is done by AppServer4RPG and on teh native side there is one SRVPGM providing a procedure fireEventP.

Thanks for your interest

Dieter