Bernd,
thanks for the elaboration.
I have switched from using invocation interface to
calling a c_main native method from a java program per your suggestion.
I had to do this to turn on method tracing, since
I couldn't figure out how to do that with the invocation interface anyway.
My class-loading problem seems to persist even after I remove all
native code, though, so it might be in my funky class loader stuff.
- Dan
-- original message from bernd kreimeier follows ---
> [EMAIL PROTECTED] wrote:
>Bernd wrote:
>> The invocation API will get you in big trouble if you use any
>> system calls redirected by green threads.
> > I just threw together a quick JNI and fileio test program, and
> > didn't see any problems.
> > Could you give us more specific details about where you've seen
> > problems?
>
> I'll rephrase and elaborate. It is not file IO, it is *system calls*.
> E.g. an open("/dev/dsp") , read/write etc. In some USENET Java FAQ
> there is an entire list of it, I can dig it up in my backlogs at home.
>
> The invocation API as such works fine with small test programs, and
> larger apps, as long as you stay away from these calls. Even if you
> do use them, you might be fine - it all depends on the linkage order,
> the libraries used, and what calls are executed in which sequence.
>
> For example, the port of the Quake2 Game DLL to Java
> (http://www.openquake.org/jquake/q2java/) has not been ported
> to Linux successfully. The problems are:
>
> a) invocation API crashes with libdl/dlopen/dlsym calls
> (thus the original Win32 approach does not work)
> b) invocation API interferes with the main() C code that
> opens the sound device
> (thus the Solaris port that linked directly, avoiding
> the libdl use, can not be ported to Linux - the Solaris
> Q2 binary is a dedicated server)
> c) invocation API intereferes with the X11 libraries the
> Q2 binary is linked against on Linux (so even if you
> avoid the sound code, the green_threads changes to
> system calls break the invocation API with existing libs).
>
>
> In short, you should be fine as long as you start from scratch,
> avoid any libc wrapped system calls changed by green_threads
> in your app, and have full control of the linkage of all
> libs used. If you take an existing app in native code (e.g.
> of the complexity of the Q2 engine) and try to retrofit it
> with an embedded JVM invoked from that app, you might have a
> lot of problems. The same might apply for adding a Java service
> to some existing legacy server etc.
>
> This seems to be a non-issue with Win32 JDK, which does not
> use green_threads. I have no information about the Solaris
> native thread JDK. I do know that the Open Group JDK does not
> support the invocation API at all (doesn't even return proper
> error codes, because they didn't bother to catch or document
> this omission).
>
>
>
> > #define USER_CLASSPATH "." /* where Prog.class is */
>
> Changing (appending) to the Linux JDK supplied class path reportedly
> crashes on Solaris, crashed in some Linux JDKs for me, too. The
> default classpath returned by the invocation is completely bogus
> in Blackdown JDK, but seems to be different in OG JDK and Solaris.
> I am not aware of any specification.
>
>
> > (*jvm)->DestroyJavaVM(jvm);
>
>
> There is a documented and reported bug in all JDK 1.1.x, that,
> according to the Bug Parade evaluation, will not be fixed in 1.2.
> DestroyJavaVM always fails and returns an error code. As the
> SMI JNI specs do not specify any issues regarding multiple
> JVM use within a single process (serial or parallel), you might
> not want to destroy a JVM. You can't invoke a second one anyways,
> the Create call fails. Might be relevant for a server that is
> supposed to restart.
>
>
> Final remark: you might be better off to avoid the invocation
> API entirely. Write a top level Java control code and main(),
> and put your legacy or augmentation native code into some classes,
> using JNI in there. It seems that Sun does not put much effort
> in the invocation API, but JNI gets some more efforts (as long
> as javac and java run, nobody cares about invocation outside
> of what these do. JNI is required by all the dirty hacks in
> the core classes, so to say).
>
>
> b.
>
>
>
