From Newsgroup: comp.lang.cobol

Hello, all,
Just posted code (pre-alpha trial) for FUNCTION JVM-CREATE and FUNCTION JVM in GnuCOBOL. https://sourceforge.net/p/open-cobol/code/HEAD/tree/branches/gnu-cobol-builtin-script/
Design discussion ongoing at https://sourceforge.net/p/open-cobol/discussion/contrib/thread/476f265d/ Working out very well, but there are now some details regarding arrays of objects to work out, to make it fit in with the simplicity of
MOVE JVM("class", "method", "spec", args[,...]) TO cobol-field
The JNI (Java Native Interface) is well documented, and the spec is simply character data to specify types "(I)I" being a function that takes an int and returns an int. "(IJ)Ljava/lang/String;" would be a function that takes an int
and a long, and returns a Java String object, etc.
The JVM intrinsic handles all of the defined types, but the [ spec, meaning Array of type that follows, is still in development. It's easy to create the structures using JNI CALLs in COBOL, but that is not really the goal of the Intrinsic; ease of use is the goal. All binary and object forms are returned as character data, as the Java .toString method would return, as the generated sending field for this Intrinsic. (Arrays currently an exception to that ease of use, for now).
Still pondering the return value for JVM-CREATE(option[,...]) but leaning to version/vendor information for the loaded VM (as character data) (or COBOL exception is set on failure). The options in this case are things like -Djava.classpath=dirnames, -verbose:class, that sort of thing, as documented in
the JNICreateJavaVM call.
A side effect of JVM-CREATE is setting the VM environment and the associated 233 function pointers (for OpenJDK 8) that will be available to the programmer for use with CALL
CALL FindClass USING BY VALUE jvm-env BY REFERENCE z"java.class.name" RETURNING
user-class-pointer
All of the names and the jvm-env core pointer are defined in a system copybook,
jvmapi.cpy. But the plan is to make needing these calls a rare thing. Exposed
when needed, but most of the common cases will be encapsulated in FUNCTION JVM(...) and something like JVM-ARRAY(...) unless a better way of specifying Java Array elements as COBOL source literals can be found.
Run samples included in the Discussion link given above.
As this is embedding the JVM, all the Java Virtual Machine .class bytecode languages are included. Groovy, Scala, Clojure, JRuby, Jython (to name some of
the more famous ones - haven't tried Kotlin yet).
COBOL has been able to call Java for quite a few years now, but this is (hopefully) a little simpler, and is encoded as an Intrinsic Function. Lots of
Java methods can be called up in one line of COBOL (with one line to initialize
the engine).
Swing will require a little care, as GnuCOBOL doesn't really know when any Java
GUI threads are complete, so that is still an issue to work out, but the very first trial with a Swing GUI using remote X11 ssh worked surprisingly well. Oh, and by the by, Peter, (I'm spillin' beans early, and probably shouldn't), but our most prolific compiler contributor has mentioned that Object COBOL is now on his active plate of work items). When that happens, GnuCOBOL will be blessed with two access mechanisms for Java; the existent METHOD-ID. definitions, and INVOKE style defined by most COBOL vendors, and this JVM(...) Intrinsic Function. For now, FUNCTION JVM(...) is first out of the gate for GnuCOBOL trials.
Unlike the other scripting engines that are part of the working branch listed above, this is not intended for user land programming. This is a full on developer tool, just very easy to wield. As the class, method, and spec lookups are character data and can be manipulated at runtime, it *could* be a user land tool, given the right type of user, but that is not the intended audience.
Aside: Intrinsic Python is ready, but not recommended for user land scripting at this time. Python has no real "restricted" mode of operation, so use of that intrinsic will need a very trusted user base. Intrinsic REXX is much safer for user land, anything goes unvetted scripting, as it defaults to restricted mode. Python, even with the old rexec imported and turned on, is still riddled with ways for scripts to wreak havoc on an application and the associated resources. Restricted mode Python was deprecated way back in Python
2.3 as too unsafe to use, even with all the efforts put into rexec. Python is so reflective that the entire system dictionary can be swapped out and replaced
from source level scripts. Use REXX for user land application programmability,
and get the benefit of Decimal arithmetic as a bonus. REXX scripts cannot change the REXX engine, so except for as yet to be discovered exploitable bugs,
Intrinsic REXX is not anywhere near as susceptible to insider and outsider malfeasance as Python is.
Back to the topic at hand:
FUNCTION JVM-CREATE(0) (and some other magic numbers) will be included, to allow for some control over the embedded JVM engine. 0 for shutdown, some other values to turn exception reporting on and off, and maybe other values as discovered before this code hits a 1.0 status. Any magic numbers will be suitably named constants in jvmapi.cpy.
And Groovy, is groovy.
Have good, make well,
Brian

SEEN-BY: 154/30 2320/100 0 1 227/0