"LiveConnect" is the Rhino feature that lets server-side JavaScript use Java classes directly through the Packages / java globals - no Java Integration step, no jar for JDK classes:
// JDK classes straight from a script task
var uuid = String(java.util.UUID.randomUUID());
var fmt = new java.text.SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
tw.local.stamp = String(fmt.format(new java.util.Date()));
var md = java.security.MessageDigest.getInstance("SHA-256");
var hash = String(javax.xml.bind.DatatypeConverter.printHexBinary(md.digest(new java.lang.String(tw.local.text).getBytes("UTF-8")))); // Java 8; Java 11+: java.util.HexFormat
// files, HTTP, XML: java.nio.file.Files, java.net.HttpURLConnection, javax.xml.parsers (see the other answers)
// your own classes in a managed server jar are visible too:
var helper = new Packages.com.example.bpm.Helper();
tw.local.result = String(helper.compute(tw.local.input));Rules and pitfalls:
- Java strings are java.lang.String objects, not JS strings - wrap with String(...) before storing in tw.local or comparing with ===.
- Numbers come back as Java boxed types; use Number(...) / parseInt.
- Arrays: JS arrays are converted to Java arrays for method parameters; Java arrays are indexable in JS but have no map - copy them.
- Implementing interfaces: new java.lang.Runnable({ run: function () { ... } }) works (JavaAdapter).
- Classes from managed jars are loaded per snapshot; static state is per snapshot class loader.
- Security: some hardened servers disable script access to Java (the CWTBG0529E family / script security settings) - then a Java Integration is the supported route; on Workflow Process Service (SaaS) direct Java access from scripts is restricted.
- Prefer a Java Integration for anything longer than a few lines: typed inputs / outputs, testable, visible in the diagram.
References