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
8.52.07
8.52.07
8.52.07
8.52.07
8.52.07

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 {} \;
/tmp/psjoa/psft/pt8/auth/WebProfile.class
/tmp/psjoa/psft/pt8/net/LoginInfo.class
/tmp/psjoa/psft/pt8/net/AppServerInfo.class
/tmp/psjoa/psft/pt8/net/ND.class
/tmp/psjoa/psft/pt8/logger/SingleLineFormatter.class

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 psft.pt8.net.ND 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.

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.

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.