From PeopleCode to Java

This section provides an overview of Java state management concerns and present examples of instantiating Java objects.

The application server is stateless, which means that it doesn’t keep any information (state) for its clients between calls to it. For one reason, calls to the application server can actually execute on different servers. When you are using Java in the application server, be careful to not leave state in the JVM that would cause your application to fail if a different application server (which would use a different invocation of the JVM) is used for subsequent calls. One method to leave state in the virtual machine is to use static (class) variables.

Similar considerations to these apply using Java in Application Engine programs, although here the difficulty arises when you try to checkpoint and then restart the program. The restart starts with a JVM invocation that doesn’t have any of the state you might have stored into the JVM before the checkpoint.

Variables of the type JavaObject cannot have global or component scope because of this lack of ability to save the state of these objects.

An example of this is issuing messages. When you're running with PeopleSoft Pure Internet Architecture and issue a message, the message is produced by an end-user action, so the Application Server gathers up its state to return it to the browser. This state saving attempts to save the current PeopleCode execution state, causing it to issue an error because of the JavaObject.

The solution is to not have any non-null JavaObject objects when the message is issued.

The following is a simple Java program:

public class PC_Java_Test{

public String pcTest(){

   String message;

   message = "PeopleCode is successfully executing Java.";

   return message;

Here is the PeopleCode that calls this Java program. Note that the JavaObject is set to NULL before the message is issued.

&java_test = CreateJavaObject("PC_Java_Test");
&java_message = &java_test.pcTest();
&java_test = Null;

In SavePreChange, Workflow, or SavePostChange PeopleCode the situation is more complicated. Usually messages with a zero style parameter (no buttons other than OK and perhaps Explain, therefore no result possible except OK) are queued up by the Application Server. They are output by the browser when the service completes, so the serialization won't happen until after the PeopleCode has finished, so you won't have to set your JavaObject to null. With other kinds of messages, you must do this.

The following is an example program creating a Java object from a sample program that generates a random password.

/* Example to return Random Passwords from a Java class */
Local JavaObject &oGpw;

/* Create an instance of the object */
&oGpw = CreateJavaObject("com.PeopleSoft.Random.Gpw_Demo");

&Q = "1";

/* Call the method within the class */
&NEW_VALUE = &oGpw.getNewPassword(&Q, PSRNDMPSWD.LENGTH);

/* This is just returning one value for now */

Suppose we had a PeopleCode array of strings (&Parms) that we wanted to pass to a Java method xyz of class Abc. This example assumes that you don't know when you write the code just how many parameters you will have.

Local JavaObject &Abc, &RefArray;
Local array of String &Parms;

&Parms = CreateArray();

/* Populate array how ever you want to populate it */

&Abc = GetJavaObject("com.peoplesoft.def.Abc");

/* Create the java array object. */

&JavaParms = CreateJavaArray("java.lang.String[]", &Parms.Len);

/* Populate the java array from the PeopleCode array. */

&RefArray = GetJavaClass("java.lang.reflect.Array");

For &I = 1 to &Parms.Len
   &RefArray.set(&JavaParms, &I - 1, &Parms[&I]);

/* Call the method. */

The following example gets a system class.

&Sys = GetJavaClass("java.lang.System");
&Sys.setProperty("", "C:\java\policy");

WinMessage("The security property is: " | &Sys.getProperty(""));

&Props = &Sys.getProperties();
&Props.put("", "C:\java\policy");

WinMessage("The security property is: " | &Sys.getProperty(""));