"UnsatisfiedLinkError: make_statement" when run in debugger

Question

I have a problem retrieving a ResultSet from a REF CURSOR --
apparently due to the JVM failing to locate requisite
native code within Oracle.
The problem is not in the code itself, but somewhere in the
configuration / environment / debugger. I conclude this because
the application runs perfectly outside the debugger (and
has, for years).
It fails only when the JVM attempts to locate a native method
within Oracle, when running the application from an Eclipse debug
launch configuration within the (newly acquired) Eclipse 3.0.1 debugger.
I should mention that we also very recently upgraded to Oracle 9i.
Therefore, I conclude the problem must be some kind
of runtime classpath / library search path mis-resolution,
or a java / oracle client code mis-match.
But I cannot find the cause.
WHAT I'VE ALREADY CHECKED / TRIED:
(1) I have quadruple-checked the jar list within the 'Classpath'
tab of the Eclipse's debug launch configuration dialog -- the
classes12.jar, etc. are those we've been using successfully in
the past.
(2a) Rather than rely on the system Path variable, I resorted to
explicitly specifying the -Djava.library.path as a VM option within
the 'Arguments' tab of the same dialog, as well. The library search
list specified within the Eclipse debug launch configuration is
identical to the system Path variable used when the application
is run outside the debugger. The behavior is the same regardless
of whether -Djava.library.path is specified in the debugger, or not.
(2b) I have modified the -Djava.library.path value specification
with forward slashes rather than backslashes as file separators
-- it made no difference. I also eliminated newlines -- it made
no difference, either.
RELEVANT ENVIRONMENT:
WindowsXP
WebLogic 6.1
Oracle 9i (recent upgrade to this version; the Oracle server is installed)
Eclipse 3.0.1
OCI JDBC Driver
THE CODE:
theStatement.registerOutParameter (1, oracle.jdbc.driver.OracleTypes.CURSOR);
if (inArgs != null)
setInputFields ( theStatement, inArgs.iterator(), 2);
theStatement.execute();
// THROWS 'UnsatisfiedLinkError' FROM THIS LINE:
theResultSet = (ResultSet) theStatement.getObject ( 1 );
Enumeration returnItems = parseResults ( theResultSet );
theStatement.close();
THE ERROR THROWN:
java.lang.UnsatisfiedLinkError: make_statement
at oracle.jdbc.oci8.OCIDBAccess.make_statement (Native Method)
at oracle.jdbc.oci8.OCIDBAccess.RefCursorBytesToDBStatement(OCIDBAccess.java:2373)
at oracle.jdbc.driver.OracleStatement.getCursorValue(OracleStatement.java:3670)
at oracle.jdbc.driver.OracleStatement.getObjectValue(OracleStatement.java:5792)
at oracle.jdbc.driver.OracleStatement.getObjectValue(OracleStatement.java:5622)
at oracle.jdbc.driver.OracleCallableStatement.getObject(OracleCallableStatement.java:698)
at appA.common.ADBInterface.executeQuery(DBInterface.java:323)
at appA.common.AEvent.initialize(AEvent.java:233)
at appA.agent.mainDlg.main(AgentDlg.java:759)
THE LIBRARY SEARCH PATH:
(The same path is specified as the value for both as the system Path variable,
and as the -Djava.library.path JVM argument.)
-Djava.library.path="C:\oracle\ora92\bin;
C:\oracle\ora92\jre\1.4.2\bin\client;
C:\oracle\ora92\1.4.2\bin;
C:\Program Failes\Oracle\jre\1.3.1\bin;
C:\Program Files\Oracle\jre\1.1.8\bin;
C:\Windows\system32;
C:\Windows;
C:\Windows\system32\wbem;
C:\Program Files\appA\bin"
ODD THING / CLUE?
Strangely, if I simply move the 'C:\oracle\ora92\bin' directory later
in the Library Search Path, the application continues to run
fine outside of Eclipse, but from within Eclipse,
the JVM now fails to locate the requisite ocijdbc9.dll and the
application produces a different error:
"java.lang.UnsatisfiedLinkError: no ocijdbc9 in java.library.path"
The ocijdbc9.dll is present within C:\oracle\ora92\bin, so I would
have expected the JVM to still be able to find it, despite simply
moving the directory later in the search path.
This must surely be telling me something I am simply too dense /
distracted to pick up on.
I cannot determine why the JVM fails to locate the make_statement
native method when run from within the Eclipse debugging environment.
Should I be looking at version changes to the classes12.jar attendant
to the Oracle 9i upgrade?
Any clues or help out there?
... KBaldwin

Answer 1

Answering my own question:
YES, it was correct to suspect a mis-match between the version of the Oracle jar files used to generate the class files and the Oracle .dll libraries.
It turned out a buddy in the group changed the debugger configuration to use a special directory containing all the third-party jar files the app depends upon, for convenience. Unfortunately, he somehow picked up an old version of one of those jar files (classes12.zip) that came from some pre-Oracle 9i installation. Once I updated the directory to contain the Oracle 9i version of that jar file, the JVM was now able to locate the requisite code at run-time, and the debugger worked.
Now the only mystery is why the hell the app ran fine outside the debugger, but I suspect the launch command is running a different application jar / class file set that was not built with the bogus old classes12.zip.