tags:

views:

200

answers:

2

Hi there,

I have an argument with my boss who is convinced that the JVM uses JNI to access native things like the file system. I think he is wrong because the JVM itself is a native code and it communicates directly with the OS - it doesn't need the JNI boilerplate to access the file system.

Please help me to clarify how the JVM works

Thanks in advance, Rosen

+2  A: 

JNI is for Java code to access native code. You are correct, the JVM IS Native code so it is directly tied to the platform it is compiled for. That is why there is a JVM for each Operating System. The Windows JVM is compiled for Windows, Linux for Linux, OSX for OSX, etc. They have all the platform specific code baked into the JVM code itself.

fuzzy lollipop
Yes, but there's no magic. When the File object or FileInputStream need to access the native file system, they use JNI to do it. Even things like java.lang.Class use JNI to get at the guts of the JVM. The JVM provides native implementations of the Java byte codes but pretty much everything else that needs native services is a JNI call.
PSpeed
PSpeed, what is the definitive way to tell ? What about the native keywords that Ninefingers mentioned?
Roskoto
@PSpeed: You are technically correct, but practically incorrect. The programmer using the JVM does not have to implement JNI to use O/S facilities for which the JVM provides an API. The difference is whether you will need to write a native shared library for each O/S and/or distribute such (as with when you use a 3rd party package which uses JNI).
Software Monkey
@Software Monkey, true. A developer doesn't practically care from day to day... but that wasn't the question.
PSpeed
@Roskoto, as I guess you've figured out by now, a method can have a "native" modifier and then no body. This means that the method will be resolved to a native function... always.
PSpeed
+3  A: 

This is a bit of a moot point really. Java Native Interfaces are a language feature to allow you to define a function call in Java that will be passed out to code that is non-java, specifically, native to the platform. If you take a look at FileOutputStream.java in the src.zip of your SDK, you'll see code like this:

    /**
 * Opens a file, with the specified name, for writing.
 * @param name name of file to be opened
 */
private native void open(String name) throws FileNotFoundException;

/**
 * Opens a file, with the specified name, for appending.
 * @param name name of file to be opened
 */
private native void openAppend(String name) throws FileNotFoundException;

/**
 * Writes the specified byte to this file output stream. Implements 
 * the <code>write</code> method of <code>OutputStream</code>.
 *
 * @param      b   the byte to be written.
 * @exception  IOException  if an I/O error occurs.
 */
public native void write(int b) throws IOException;

So I would say if the question is - does the class library use the same notation I do to access external system-level library calls I think the answer would be yes.

However, the Java Virtual Machine that interprets java bytecode and applies these rules is definitely native code - I suspect also that for the sake of naming (different "native" systems use totally different APIs) unlike native calls direct to libraries, these calls are picked up by the VM and handled by the VM.

Ninefingers
I think that the "native" keyword dosen't necessary mean JNIhttp://java.sun.com/docs/glossary.html#Nnative A Java keyword that is used in method declarations to specify that the method is not implemented in the same Java source file, but rather in another language.
Roskoto
Aaaah thanks. I guess the bit that makes it JNI then is the System.loadLibrary () call.
Ninefingers
@Roskoto: But if you look into the JVM source code (at least Sun's), you'll see that most if not all native methods in the class library are actually implemented using JNI. Why should the VM use a different technology to implement necessary native functionality in the library classes?
jarnbjo
In fact, all the "native" keyword means is that the method will be resolved to a native function in the currently loaded set of native shared libraries. Whether you've compiled your own JVM to include a bunch of your own shared libraries or specifically load them with System.loadLibrary() isn't related to whether you call it JNI or not.
PSpeed
@PSpeed which sounds like my conclusion... thanks!
Ninefingers
Yeah, and shared library necessarily has a look-up table of functions... whether Windows DLLs or Unix so files or whatever. A native method gets turned into a look-up for a full qualified name containing the full class name and method signature. So you could compile your own JVM to load all of your shared libraries and never call System.loadLibrary()... and you'd still be using JNI. That's all the built-in native code is doing.
PSpeed
That's an interesting idea... thanks for your input!!
Ninefingers