On Fri, 17 Jul 2009, Arne Vajh?j wrote:
Tom Anderson wrote:
On Thu, 16 Jul 2009, Mike Schilling wrote:
Arne Vajh?j wrote:
Mike Schilling wrote:
Developing JNI would still be a bit onerous, but shipping JNI-using
apps would be a breeze. And adding new platforms would be
straightforward for either the developer or the end-user.
The problem would be that the library is not loaded by JVM code
but by OS code - there may be OS'es where it would be impossible
to let the JVM specify the path to the OS.
But that's Sun's problem, not mine.
Less silly response: if the JVM has to copy the library from the
classpath to the OS-required location, that's fine with me. Anyway,
while I know of OS's which specify the *default* location for shared
libraries/shareable images/DLLs, all have system calls that allow
them to be loaded from a location given by the caller.
Since the JVM manages to link code that it's made up itself, this
should be a fairly minor challenge.
No guarantee that JVM use DLL's itself or that the process has write
permission where the DLL's reside.
No, and it doesn't need either of those things. If it can read the DLL
file, it can read it into memory, and then link it as if it was code
that it had compiled itself. The JVM needs to understand the library
format, but that's a matter of code, not one of capabilities. Even if
the JVM isn't a JIT, because it's a C program in the end (or rather,
assuming it is a C program or similar), it should be possible for it to
read in a library as a file, make it executable, then find and jump to
the relevant point in it.
If you don't do that, then you don't need write permission. But