Bernd Kreimeier wrote:
> ... The very same classpath
> that works to load the main Java class (import/javac)
> does not work when I call env->FindClass in the
> native code. The same source works with Japhar
> (unfortunately, Japhar has other problems).
>
> The error appears in 1.1.5 and 1.1.6v3. I rigged up
> a test program, available on demand. I can load classes
> that are not in packages, from the directories set
> in the classpath (invocation API or bin/java). I can't
> load a class that is in a package (below the root
> directory), from inside a native method implementation.
I tried the invocation API today; seemed to work ok.
Where I ran into trouble was in loading classes.
The same code seemed to work fine in Win95 with Sun JDK1.1.6,
but failed identically every time with Blackdown JDK1.1.3v2 and 1.1.6v2.
The code works fine if I invoke the problem code from
a regular java app instead of from a C program that
dynamically loads classes.
Here's the sequence of calls:
C main()
initialize vm
load init class
load my classloader class
call init class static method to open jdbc connection
call my classloader class to load score_65 class from a jar file
call score_65 class method, pass it the jdbc connection
score_65 tries to retrieve record from database
jdbc driver tries to load private class (it's on classpath)
vm opens class file successfully
vm reads bytes from class file
vm reports "class not found"
Here's what was printed out:
java.lang.NoClassDefFoundError: twz1/jdbc/mysql/jdbcMysqlField
at twz1.jdbc.mysql.jdbcMysqlResult.buildColumn(jdbcMysqlResult.java:392)
at twz1.jdbc.mysql.jdbcMysqlResult.getResult(jdbcMysqlResult.java:258)
at twz1.jdbc.mysql.jdbcMysqlStmt.mExecQuery(jdbcMysqlStmt.java:318)
at twz1.jdbc.mysql.jdbcMysqlStmt.executeQuery(jdbcMysqlStmt.java:293)
at score_65.scoreReceived(score_65.java:61)
So I wonder if I'm running into class loader magic shit here?
Note that the class file *is opened successfully* and bytes
are read from it, yet it is reported as not really there.
Could it be stronger bytecode verification is going on
because this class is being loaded during the
execution of a class that was loaded by my loader?
The jdbc driver worked fine when I ran it from a normal app.
Clearly, I should try doing my class-loading magic without
involving JNI or the invocation API, to see which of the
two is 'at fault'.
My code is available to the maintainers if they want to see it.
They probably want to wait until after I poke into this a bit
more, though.
- Dan
