libjvm libraryPL/Java installation requires knowing the filesystem paths
to some items produced by the build, and also to the libjvm
(or just jvm on some platforms, like Windows)
shared object for the Java Runtime Environment that is to be used.
To find that object can be a bit of an exercise, because of
the variety of locations and naming schemes for the Java runtime on
different platforms. It may be simplest to do a filesystem search for
the name libjvm.* under the Java home directory (which is reported
by mvn -v assuming the JRE that you used for running Maven is the
one you intend to use at run time).
The filename extension may be .so on many systems, .bundle on Mac OS X
(see the Mac OS X build notes for more about OS X),
or .dll on Windows. As Windows also leaves off the lib in front, on
that platform you would look for jvm.dll.
If a tool such as Linux strace is available to see what files are opened
by a process, this works:
strace -e open java 2>&1 | grep libjvm
The methods above may find the libjvm object on a very specific path
(for example, including the JRE vendor, major, minor, version, and patch
numbers). If that exact path is used to SET pljava.libjvm_location
in PostgreSQL, PL/Java will stop working as soon as the next Java patch
is applied.
Typical OS distributions will also provide some less specific, alias
paths to the Java runtime environment. On Linux, for example, there
may be a /usr/lib/jvm directory with entries using only the major
and minor Java version that are symbolic links to the fully specified
JRE. By using such an alias instead of the absolutely specific Java
path, you can avoid headaches when Java is updated.
By the same token, the directory of aliases may contain a completely
generic one like jre, linked to whichever Java version is considered
current. Using an alias that is too generic could possibly invite headaches
if the default Java version is ever changed to one your PL/Java modules
were not written for (or PL/Java itself was not built for).