JPOs and Program User Access

Consider this sample code for JPO B.

public class ${CLASSNAME} extends ${CLASS:A} implements ${CLASS:C}
{
    public int mxMain(Context ctx,String[] args)
	{
		${CLASS:D} dObject = new ${CLASS:D}(ctx);
		dObject.methodOfD();

		methodOfA(ctx);

		retVJPO.invoke(context, "D", null, "mxMain", null);

_mql = new MQLCommand();
_mql.executeCommand(ctx, "execute program D");
	}
}

The program above can be run in any of the following manners:

1. JPO B extends JPO A and a method of A is run on an object of type B as shown by methodOfA.
2. JPO B implements JPO C. References to C objects really execute a different program object.
3. JPO B runs a method of JPO D without using JPO.INVOKE as shown with dObject.
4. JPO B uses JPO.INVOKE to run JPO D.
5. JPO B uses MQLCommand to run "execute program <program name>" as shown with _mql.

In the first 3 cases, execution is handled solely by the JVM, so that the 3DSpace is never aware of when the methods of another JPO get invoked and returned. In these cases, the user of program B will remain in effect and the users, if any, of programs A, C and D, are ignored. In cases 4 and 5, execution goes through the kernel code and the programs are invoked as program objects, not just Java code by the JVM, and so the usual rules apply.