×
Tips and Techniques

Java and PeopleCode Tips and Tricks – Part 1

By Larry Grey • February 28, 2006

Since Java is the language of choice for the Oracle Fusion applications, I thought it would be nice to have some posts that show some good tips and tricks related to using Java within PeopleSoft today. As I mentioned in the previous post there are a few quirks in the way that Java and PeopleCode work together. Well, as Bill Cosby once said, “I told you that story so that I could tell you this one” 🙂

The quirk that we’ll cover today has to do with the way that the mapping between PeopleCode and Java datatypes works. I have a few quirks that I’ve known about for awhile, but I got bitten by this one just recently while working on a follow on to a previous blog entry about version control and PeopleTools. The idea was to show an example of using the JavaSVN java library from PeopleCode to be able to place application data under version control (application setup/configuration data, not something like Ledger entries).

The library works great directly from within Java code, but I hit some strange behaviour when trying it from PeopleCode, and it turned out that the fault is in the way that PeopleCode was passing Null into the Java side.

To simplify things, imagine that you have the following Java class that exposes these static methods.


package com.greysparling.demo;

public class JavaPeopleCode1 {

public static boolean IsObjectNull(Object test1) {
if (test1 == null) {
return true;
}
else {
return false;
}
}

public static boolean IsStringNull(String test2) {
if (test2 == null) {
return true;
}
else {
return false;
}
}

}

You’d think that these methods would each return True when you pass a Null from PeopleCode into them and False otherwise. When we call these from a short AppEngine program (side note: using AE is a great way to test out these sorts of quick test things) we see otherwise.


Local String &sClassName, &sPeopleCodeString;
Local JavaObject &demo;

&sClassName = “com.greysparling.demo.JavaPeopleCode1”;
&demo = GetJavaClass(&sClassName);
&sPeopleCodeString = “Testing”;

Warning (&demo.IsObjectNull(&sPeopleCodeString));
Warning (&demo.IsObjectNull( Null));

Warning (&demo.IsStringNull(&sPeopleCodeString));
Warning (&demo.IsStringNull( Null));

Here’s the output that we get from running this (miscellaneous junk from the log has been trimmed out).


False
True
False
False


Notice that last one? We would have expected that to return True since we’re passing Null. It turns out that any object type that PeopleCode has a direct mapping for (such as a PeopleCode string with java.lang.String), you can’t pass null. Or more accurately, if you pass Null from the PeopleCode side, you won’t actually get null on the Java side.

Annoying eh?

The workaround for this is to create some additional Java glue code and call that from the PeopleCode side.

Labels:

Stay Updated

3 Replies to “Java and PeopleCode Tips and Tricks – Part 1”

  1. In the example posted here, you would have a Java source file called JavaPeopleCode1.java, which would compile to a Java .class file called JavaPeopleCode1.class.

    To get this to work inside of a PeopleTools application server, you’d copy the JavaPeopleCode1.class file to c:pt848classcomgreysparlingdemoJavaPeopleCode1.class

    Adjust your PSHOME as needed.

    That is the easiest way to do it. PeopleTools also includes all of the .jar files that it finds in c:pt848class as part of the classpath, but those are only read at startup time, so if your Java code is in a .jar file, you’ll need to restart each appserver/process scheduler to get it to recognize the new file out there.

    There are some other options (such as modifying the appserver domain configuration), but you shouldn’t need to get into that just to get started.

  2. When I call java code from people code its pops up an error saying no class found.Classpath not set though I set the class path to PS_HOME it shows the same error.Can you please explain initial installations steps if any

    Thanks

  3. Exciting topic! Looking forward to the rest of the series.

    I have limited experience in using Java classes in PeopleCode. One thing I’ve noticed is that implicit PeopleCode String to java.lang.String conversion is not performed consistently. When calling a JavaObject method passing a PeopleCode string, there were times that I get a runtime error stating that a matching method signiture could not be found. This is easily fixed by explicitly converting the PeopleCode string to java.lang.String using CreateJavaObject.

Comments are closed.

Request a Demo