How much does java depend on native methods ?

[David Jason]

What are the tasks/functionality provided to Java by its native methods ?
Would Java be severely crippled if it was not allowed to use native methods ?

[Paul Clapham]

Well, anything in the Java API which needs to interface with features of the operating system ultimately has to involve native code. And since these features include basic things like working with threads and allocating memory, that means that Java programs couldn't run without using native methods.

[David Jason]

Paul Clapham wrote:Well, anything in the Java API which needs to interface with features of the operating system ultimately has to involve native code. And since these features include basic things like working with threads and allocating memory, that means that Java programs couldn't run without using native methods.

For that reason, I think C++, C or even assembly are better because they let you see how things work at low-level or system level.
You also learn things like garbage handling.

The only advantage of java which makes it more attractive would be security and portability ?

[Stevens Miller]

Since the JVM is a native executable, one could say that Java itself would not be able to do anything without native code. But "native methods" are very specific things. These are methods defined for Java classes that are compiled not to Java bytecode, but to the instruction set of some other run-time platform (be that the actual CPU of your machine, or yet another virtual machine other than the JVM). As such, when you declare a native method for a Java class, you will end up writing that method's code in some language other than Java, compiling it into a loadable library, and calling a Java API routine that will load the library for you. After that, your code may call native methods for classes that contain them in exactly the same way as it calls methods that were written in Java itself.

Now, internal to some of the standard Java classes I suppose it is possible that there are native methods, but I have never found evidence of that. If they exist, they would have to load the necessary run-time libraries containing the executable native code, and I also don't recall ever seeing evidence that you needed to provide any such libraries for Jave SE. Certainly, as a Java programmer, you could write limitless amounts of code and never, ever have to deal with native methods.

Then again, you could be me. I'm working with video cameras that, on Windows, use DirectShow. As far as I can tell, there are no pure-Java options for getting video from a DirectShow capture source. So, I have had to write a tonne of C++ code, learn how to use the Java Native Interface (the "JNI"), and provide the native methods necessary to permit my Java objects to control enough DirectShow functions to acquire video from the cameras I am using, and make the video available to the rest of my Java application. I studied this for a long time and simply never found any way to do what I am doing that would not require native methods.

Thus, I think the answer to your question is, "It depends on what you are doing." As a broad answer, Java seems to need native help when you want to deal with hardware beyond the basic model of a desktop computer (that is, anything much beyond keyboard, screen, mouse, printer, and disk drives). If you want to use a camera, you need to use native methods. If you want to use a game controller, same thing. Now, a lot of this has been done for you. For example, some people speak highly of "JInput," when you want to use a game controller (haven't tried it, myself). Done well, a class library can give you support for your application by making use of native methods, and can hide that fact from you. From your perspective, calling a native method and calling a "normal" Java method look exactly the same. So long as the necessary library is present and your class library knows how to load it for you, you'll never have to know that native methods are involved. (Indeed, the entire library the class needs to load can be "hidden" in the .jar file that most likely is how you got your class library.)

Learning to use JNI is like a lot of coding experiences: it's a challenge to learn, but easy to use once you have learned it. FWIW, I'd advise avoiding it until you discover you need to do something that Java just can't do, but another language you know can. It might be tempting to jump onto the JNI early, if you are a new Java coder and already know another language, as that way you can rely on your existing skills if you run into something that you can't do yet in Java. Don't give in to that temptation. First of all, that way leads to The Dark Side, and can stop you from finding out that Java might be better for what you are doing than you knew. And, second, the JNI is a real challenge to master. No matter how much easier it might be for a good C++ programmer who is just learning Java to do a given thing in C++ rather than in Java, in most cases, learning how to use the JNI is harder than learning the Java you would need to avoid the C++ altogether.

I'm glad I know how to use the JNI, but I can assure you that I only use it when I am convinced that Java just cannot do what I need to do.

HTH.

[Paul Clapham]

David Jason wrote:For that reason, I think C++, C or even assembly are better because they let you see how things work at low-level or system level.
You also learn things like garbage handling.

I suppose if that's one of your goals, then those languages are "better". But that seems like a very peculiar goal for a programmer to have. In my case, for example, I use a programming language to write code which gets things done, rather than as a tool to investigate the inner workings of the operating system.

[Stevens Miller]

David Jason wrote:
The only advantage of java which makes it more attractive would be security and portability ?

Uh... no, I'd say there are other advantaages.

I don't want to get into a debate about what makes Java a good choice, since that, again, depends on what you are doing. If you want to look at low-level stuff in Java, you can. The JVM is, for that purpose, your CPU. If you are a bit-twiddler (like I have been, at times), you can dig into the bytecode just the way you can dig into machine code. As for garbage, Java is a managed language so, unlike C and C++, you have nothing really akin to "free()" that you need to call. You can find about a billion-trillion lines of online comments devoted to whether or not managed languages are superior to unmanaged languages. But, let me save you some time, since I have personally read all billion-trillion of those lines: the answer to whether or not a managed language is superior to an unmanaged one is, "It depends on what you are doing."

FWIW (again), when I learned C++, I sort of said to myself, "Self," I said, "this is the last goddam computer programming language you are going to learn." I deliberately held off Java for years. Then, because it was free, I downloaded it and NetBeans and... well, let's just say I like Java now and let it go at that. Do I like it better than C++? Well... let's just say I like Java now, and let it go at that...

[Jayesh A Lalwani]

David Jason wrote:

The only advantage of java which makes it more attractive would be security and portability ?

Only? Only?! That's like saying the only advantage planes have over cars is that they can fly :D

[Matthew Brown]

David Jason wrote:For that reason, I think C++, C or even assembly are better because they let you see how things work at low-level or system level.
You also learn things like garbage handling.

The only advantage of java which makes it more attractive would be security and portability ?

Interesting how people see things differently. I'd say that those reasons you think that C/C++ is better are exactly the reasons I'd prefer Java (or C#, or most modern languages) over them. It depends what sort of programming you're doing, of course, but for the majority of applications you don't need to know how things work at a low level.

[Paul Clapham]

I don't have a whole lot of data points, but it seems to me that people who think that being able to see what goes on at a low level only limit their vision to a small subset of operations.

For example as far as I know, C and C++ accept the operating system's version of floating-point arithmetic without question and don't allow the user to see what goes on inside that. Are there C++ programmers who reject that kind of paternalism and write their own floating-point arithmetic routines?

[Stevens Miller]

Paul Clapham wrote:For example as far as I know, C and C++ accept the operating system's version of floating-point arithmetic without question and don't allow the user to see what goes on inside that. Are there C++ programmers who reject that kind of paternalism and write their own floating-point arithmetic routines?

Actually, you can play some tricks that will let you get into that. For example, this code lets you change a floating-point value by fiddling with its bits directly:

#include <stdio.h>

main()
{
	float	f;
	long*	pl;

	f = 1.0 / 3.0;
	pl = (long*)&f;

	printf("0x%08x %f\n", *pl, f);

	*pl |= 0x4000;

	printf("0x%08x %f\n", *pl, f);
}

Run the above you get this:

0x3eaaaaab 0.333333
0x3eaaeaab 0.333822

I don't think you can get into the internals of primitive types in Java like that. You wouldn't have much reason to do it in any language, but you can if you want to, in C.

I actually do find this a little frustrating about Java, sometimes, when I am dealing with rasters of image data. The ImageIO methods sometimes do well with pixels treated as integers, sometimes treated as three-byte RGB triplets, sometimes as four-byte quads, and so on. Each treatment has its advantages, but you pretty much have to pick one for any given raster (well, you can copy the raster from one Image to another, but that's kind of like dying a person's hair by performing a head-transplant).

[Jesper de Jong]

Stevens Miller wrote:Now, internal to some of the standard Java classes I suppose it is possible that there are native methods, but I have never found evidence of that.

There certainly are. You can find the source code of the classes of the standard library in the file src.zip which is in your JDK installation directory. If you look through those, you'll see that some classes do have native methods.

Stevens Miller wrote:I don't think you can get into the internals of primitive types in Java like that.

Not as directly as in C (mainly because there are no pointers), but you can fiddle with the bits of floating-point numbers; see for example the methods Float.floatToIntBits() and Float.intBitsToFloat().

[Stevens Miller]

Jesper de Jong wrote:

Stevens Miller wrote:Now, internal to some of the standard Java classes I suppose it is possible that there are native methods, but I have never found evidence of that.

There certainly are. You can find the source code of the classes of the standard library in the file src.zip which is in your JDK installation directory. If you look through those, you'll see that some classes do have native methods.

Are any of those "real" native methods, Jesper? I don't know much about intrinsics, but the ones I spot-checked (Object.hashCode(), the trig functions in StrictMath) all appear to be built into the JVM, rather than compiled into libraries you load at run-time. There are a few .c and .h files, but those appear to be for startup, not object support.

Jesper de Jong wrote:

Stevens Miller wrote:I don't think you can get into the internals of primitive types in Java like that.

Not as directly as in C (mainly because there are no pointers), but you can fiddle with the bits of floating-point numbers; see for example the methods Float.floatToIntBits() and Float.intBitsToFloat().

Those routines do convert bits back and forth to equivalent floating values, but you have to have a bit of faith. The doc on intBitsToFloat, for example, says it will give you "the float value corresponding to a given bit representation. The argument is considered to be a representation of a floating-point value according to the IEEE 754 floating-point 'single format' bit layout." Now, the Java Tutorial does say the primitive values are stored just the way you would expect them to be stored (IEEE 754 is used for floats, for example), so I think you are correct that these conversion routines, in the end, amount to the same thing as being able to change the bits directly. You just have to trust the routine to make it happen the way you expect. (No problem for me, but if someone wants to see what's happening at the hardware or bytecode level, that may not satisfy them.)

[Jesper de Jong]

Stevens Miller wrote:Are any of those "real" native methods, Jesper? I don't know much about intrinsics, but the ones I spot-checked (Object.hashCode(), the trig functions in StrictMath) all appear to be built into the JVM, rather than compiled into libraries you load at run-time. There are a few .c and .h files, but those appear to be for startup, not object support.

I don't know where those native methods are implemented. If you look into the bin directory of Oracle's JRE for Windows, for example, you'll see that there's a whole list of DLLs there. I guess that the native methods in the standard library are called via the exact same mechanism (JNI) as when you'd create a native method and corresponding native library yourself. There's for example a nio.dll which probably contains native method implementations for stuff in Java's NIO API.

[Stevens Miller]

Jesper de Jong wrote:

Stevens Miller wrote:Are any of those "real" native methods, Jesper? I don't know much about intrinsics, but the ones I spot-checked (Object.hashCode(), the trig functions in StrictMath) all appear to be built into the JVM, rather than compiled into libraries you load at run-time. There are a few .c and .h files, but those appear to be for startup, not object support.

I don't know where those native methods are implemented. If you look into the bin directory of Oracle's JRE for Windows, for example, you'll see that there's a whole list of DLLs there. I guess that the native methods in the standard library are called via the exact same mechanism (JNI) as when you'd create a native method and corresponding native library yourself. There's for example a nio.dll which probably contains native method implementations for stuff in Java's NIO API.

I think it's worth making a distinction between .dll files that are part of the JRE (and, I assume, are loaded by the JVM when it needs them) and native methods that are in a library your application has to load. Again, since the JVM is a native-code executable, it's fair to say that all Java programs rely on native code to run.

I'm not sure those JRE .dll routines are called with the same mechanism as is used by the JNI. From what I'm reading online today, it appears that intrinsic functions are compiled directly into the virtual machine. That's already running in native mode, so there's no need to use JNI to call its own routines.

Maybe I'm making a meaningless distinction here, but what I'm seeing is a difference between a class that includes native sources as part of the class definition, and a class that calls a native method that is part of the JRE, not part of the class definition. It doesn't appear to me that the latter case would use the JNI, nor that you would be able to find the source for those methods in the JDK.

[Jesper de Jong]

Ok, but that's a discussion about the implementation details of the JVM you're using. It could very well be there's some optimization in Oracle's JVM, I really have no idea. If you'd really want to know, you could dive into the source code of OpenJDK. But it's not going to be an easy project to comprehend.

[Stevens Miller]

Jesper de Jong wrote:Ok, but that's a discussion about the implementation details of the JVM you're using. It could very well be there's some optimization in Oracle's JVM, I really have no idea. If you'd really want to know, you could dive into the source code of OpenJDK. But it's not going to be an easy project to comprehend.

That's my point: I don't think you're going to find the source for the methods declared "native" in the JDK, because they are actually compiled into the JVM. What you need, if you want to see that source, is the JVM source code, not the JDK.

I'm finding it a challenge to locate authoritative docs online about this (which probably means it's not a topic worth getting too concerned about), but I found some C++ source that appears to be for the JVM, which lists the "native" intrinsics that are compiled into it, rather than as part of the JDK. I guess it's one of the advantages of a virtual machine that you can change the implementation of what is originally a method call to something the compiler can simply code in-line. Of course, your compiler has to be savvy about which functions are intrinsics, I suppose, but a lot of the non-authoritative stuff I've found (mostly comments on stackoverflow.com) suggest that's exactly how it works.

[Jesper de Jong]

The src.zip included with the JDK only contains the Java source code; it indeed does not contain the source code of the native methods, which is probably in C or C++.

You can find that source code in OpenJDK. OpenJDK is Oracle's open source version of their own JDK, JRE and JVM. As far as I know, more than 95% of the code of Oracle's JDK is shared with OpenJDK. Interesting if you'd want to study the internals of the JDK, JRE and JVM, but surely a daunting project to undertake.

[Stevens Miller]

I downloaded OpenJDK, but can't seem to find the C++ source. Probably, I downloaded the wrong thing. Regardless, here's an answer to a question on stackoverflow.com that confirms your description.

Wish I could find that directly in the OpenJDK source I have, but that will just have to wait for another day.

[Jesper de Jong]

Did you download a pre-built version of OpenJDK? That doesn't include the sources. You can get a source bundle or browse the code online (from the Mercurial source code repository).

[Stevens Miller]

I used the Fedora built-in software manager to download the source. Got a whole bunch of .java files, but apparently only the same ones as are in the src.zip I started with on Windows.