Corey Cole

Greenhorn
+ Follow
since Sep 04, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Corey Cole

And now the circle is complete...
I was being naive in trying to instantiate a ClassLoader
object via it's constructor. Yes, javap shows the ctor
inside the classfile, but the _real_ method you want to call is
"getSystemClassLoader".
Here's the sample code in working form:

And please, no making fun. I've been working on this
for 12 hours straight. What finally clued me in is the
Delphi(!?) source found here: http://home.pacifier.com/~mmead/jni/delphi/javadpr/javadpr_dpr.html
Regards, and thanks to the JavaRanch for letting me talk to myself.
23 years ago
Not to answer my own question (mostly because I don't have an answer), but I've narrowed the problem down.
I wasn't checking for exceptions after each JNI call. When I check for exceptions after each call, both the IBM and Sun JVMs
fail at the same point. I guess the IBM JVM is a little more lenient than the Sun JVM.
Anyways, it appears the issue is my creation of the ClassLoader object. I've never really played with ClassLoaders in pure code, so it's possible I'm not creating the loader object in the correct context...
23 years ago
I'm attempting to create yet another Java service tool. After looking at the source code that comes with the Microsoft Java SDK, I found that their jexegen/jntsvc programs bind string params into a string table and raw classfile data into RT_RCDATA resources within an exe.
After some google searching, I found some good examples on how to update/read resources. However, I'm stuck when it comes to
actually instantiating the class. When I try the IBM JVM, I get to the point where I load the class but can't find the methodID for the static "main" method. When I use the Sun JVM, I don't even get that far, and my call to DefineClass returns a NULL.
Here's the source to an analog program (no EXE/DLL resource stuff, but it's pretty damn close):

(yes, it's getting to be a hack job, and yes, it's silly
to hardcode classnames in there...)
Finally, the "Hello" class it refers to is just a simple
Hello World.
Any pointers would be greatly appreciated. Thanks.
23 years ago
The return value of JNI_CreateJavaVM is 0 if there's
no problem, and a negative number if there was an error.
From jni.h:
#define JNI_OK 0 /* success */
#define JNI_ERR (-1) /* unknown error */
#define JNI_EDETACHED (-2) /* thread detached from the VM */
#define JNI_EVERSION (-3) /* JNI version error */
#define JNI_ENOMEM (-4) /* not enough memory */
#define JNI_EEXIST (-5) /* VM already created */
#define JNI_EINVAL (-6) /* invalid arguments */
Granted, this topic is quite old, but hopefully if Google picks it up it'll help someone down the road
23 years ago
First thing to do is to check in src.jar.
Sun and IBM both provide the c source for java.exe
so you can see how they do it.
Next, your CreateJavaVM call should look like
JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
That'll fix your compilation problem.
If you're using a Java2 VM (and I don't know why you wouldn't)
forget about JDK1_1InitArgs. Here's how I initialize my
JVM (Windows, which is why I use BOOL...):
JNIEnv *env = 0;
JavaVM *jvm = 0;
BOOL initJVM() {
#define numOptions 2
JavaVMInitArgs vm_args;
JavaVMOption options[numOptions];
options[0].optionString = "-Djava.compiler=NONE";
//options[1].optionString = "-verbose:class";
options[1].optionString = "-Xcheck:jni";
jint ret;
vm_args.version = JNI_VERSION_1_2;
vm_args.options = options;
vm_args.nOptions = numOptions;
vm_args.ignoreUnrecognized = TRUE;
ret = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
if (ret < 0) {
cout << "Can't create JVM! Error: " << ret << endl;
return FALSE;
}
return TRUE;
}
Beyond that, you've got my sympathies. I'm on my second day
of trying to work around an InstantiationException when I pass
raw bytes to JNI's DefineClass function...
23 years ago