Determining psjoa.jar Version

I recently answered a question on the OTN forums that I thought was interesting and figured I’d detail it a little further here.  Someone was using psjoa.jar to interface with a remote PeopleSoft system and wanted to verify what PeopleTools version a specific psjoa.jar file was from.  First a little background on psjoa.jar.  This file is a package of java classes that can be used to interface with PeopleSoft.  It’s required by a multitude of 3rd party applications and adapters which wish to interface with PeopleSoft.  It can also be used to expose Component Interfaces to your own Java applications, which I may detail in a future post shortly.

Here’s how I found the version and created the solution:

First it helps to know that psjoa.jar can be found in $PS_HOME/appserv/classes.  So I ran unzip -c psjoa.jar | strings |grep 8.52.  8.52 being my current major tools release version for this file.  unzip -c extracts to stdout and then I piped that to strings and from there to grep.  If your wondering why I ran unzip it’s because the jar contents are compressed which garbles everything useful that strings might give me from each individual file in the jar.

$ unzip -c psjoa.jar | strings | grep 8.52

Okay, so I knew the version was in there a few times and since strings was able to see it, it’s in a readable format.  Now lets find out where exactly, so I unzipped psjoa.jar to a temp directory and I ran find on the directory using the -exec option to run grep -l on every file so I would just get the file name of every file that matches.

$ mkdir /tmp/psjoa
$ unzip psjoa.jar -d /tmp/psjoa/
$ find /tmp/psjoa -exec grep -l 8.52 {} \;

Okay, so I got a few options and these sound promising… promising in that they hopefully won’t disappear in the next version.  So I had half a solution, by grepping for a regex pattern that matches a tools release. So something like

unzip -c psjoa.jar |strings |grep 8″\.”[4-5]

would work, but I was looking for something more (as was the poster since they were on Windows and was trying to build this into something web based on their end I think).  So I imported psjoa.jar into a project in Netbeans to take a look.  After looking at the above classes in Netbeans I found ND would be the best class.  ND is an interface that contained public static final variables only, that’s perfect.  I showed the OP he could just import and then print out the variable TOOLS_REL and build that into a jsp page or however he would like to deploy it.  One thing to remember about this is that final static primitive or String constants will be replaced to their value at compile time, the bytecode will not contain a variable anymore but the value directly.  So just compiling the program with ND implemented will cause every version we check to always be that of the file used to compile and that won’t do us any good.

same version

Notice in the above screenshot both psjoa.jar and psjoa2.jar indicate the same PeopleTools release.  But psjoa.jar is from 8.51 and psjoa2.jar is from 8.52.  So since this a really simple single purpose utility with only one line I created a new ND.class to use at compile time that forced the variable to no longer be constant.  The cloned ND.class is only for compile time, during runtime we find the real file and the compiled code  needs to look up the value from the file every time.  Exactly what I wanted.  Now I have a simple cross platform utility to check the version.

different version

I’ve posted this program in my new Downloads section.  Because PeopleTools 8.53 is now built using Java 7, this utility is best run with the Java 7 JRE.  I compiled it with support back to Java 5, however if your using Java 6 to look at a psjoa.jar file from 8.53 which was built with Java 7 then you’ll get the error “Unsupported major.minor version 51.0” because psjoa.jar itself is not compiled with the backwards compatibility.  51 in the error indicates the ND.class being imported requires Java 7.  PeopleTools 8.49 was the first version to use Java 5, so this version of the utility will be limited to testing 8.49+ psjoa.jar files.  I’ve run it on 8.49, 8.51, 8.52, and 8.53 and it worked on all 4 of those.

3 thoughts on “Determining psjoa.jar Version
  1. I am using application built using JDK 6 which calls psjoa.jar file. With people tools upgrade, application has stopped working. If i use psjoa.jar from PS server , it gives unsupported java version as application is on JDK6.
    Therefore rather than making this application compatible with JDK7, i was exploring option of having having psjoa.jar for 8.53 peopletool version compatible with JDK 6?? Not sure whether that is possible or not.
    If its possible, how can i reverse engineer psjoa.jar to make it compatible for JDK 6 version??

    • Unfortunately I’m not aware of a way the 8.53 PeopleTools psjoa.jar file can be safely used with Java 6. Breaking 3rd party/external apps is always a risk in an upgrade. Oracle decided to move 8.53 to Java 7 and I can only speculate that they started making use of features that were released in 7 within the code.

      You can read about Java 7 compatibility

  2. Hello vinay2808 ,

    We are in the same boat while trying to do PT upgrade.
    Could you share your experience reg how you resolved this issue?

Leave a Reply

Your email address will not be published. Required fields are marked *