Native methods and libraries are bits of executable code that are written in the traditional way: They are written in
a language such as C or C++ and compiled into a platform-specific library such as a DLL or a shared library.
Inside your Java applications you can gain access to the functions inside those libraries, allowing you to create
a sort of hybrid Java and native code application. Although using native methods can give you some extra benefits
Java does not provide (such as faster execution or access to a large body of existing code),
there are significant disadvantages in using native methods as well.
advantages and disadvantages of using native methods
Advantages of Using Native Methods
There are several reasons that you might want to consider using native methods in your own Java programs.
By far the best of these reasons are
Gaining access to special capabilities of your computer or operating system
Needing the extra speed that native methods provide
Needing access to a large body of existing code
The first, and by far the best, reason to implement native methods is because you need to utilize a special capability
of your computer or operating system that the Java class library does not already provide for you. Such capabilities
include interfacing to new peripheral devices or plug-in cards, accessing a different type of networking, or using a
unique, but valuable feature of your particular operating system. Two more concrete examples are acquiring real-time
audio input from a microphone or using 3D "accelerator" hardware in a 3D library. Neither of these is provided to you
by the current Java environment, so you must implement them outside Java, in some other language (currently C or any
language that can link with C).
The second, and often illusory, reason to use native methods is speed. The argument has been made that because
interpreted bytecode is terribly slow in comparison to how quickly native code runs (and it is far slower,
as much as 25 times slower), Java code is unsuitable for most applications. In many cases this simply isn't true,
or you may be able to extract a fair amount of speed out of your Java program without resorting to native methods
(as we'll explore in greater detail later in today's lesson). If, however, your Java application uses very
processor-intensive calculations (for example, number crunching or 3D rendering), using native methods for
the speed-critical functions and Java for the more general interfaces creates a system with more benefits than
a system written in either pure native code or pure Java. In fact, the Java class library uses this approach for
many critical system classes to raise the overall level of efficiency in the system. As a user of the Java
environment, you don't even know (or see) any side effects of this (except, perhaps, a few classes or methods
that are final that might not be otherwise).
The third reason to use native classes is if your project has a large body of existing code (what's called legacy code, which may be hundreds of lines of code written and maintained by other people over the years). As a good Java programmer and advocate you would, of course, want to port this large body of code to Java. However, real-life considerations of time and resources often don't allow this option. Native methods allow you to write a single interface to that code through Java and link into the existing code as it's needed.
Disadvantages of Native Methods
After reading the advantages of using native methods, you may be all set to jump to the section on how to use them
and skip this section. Don't. For every good thing native methods provide in your Java code, they take away a benefit
that Java provides in the first place: the ability for your code to run anywhere and be easily ported from one system
to another.
Using pure Java, an application or applet can be run on any Java environment in the world by downloading it via the
Web or by simply loading the class file on that system. Any new architectures created-or new operating systems
written-are irrelevant to your code. All you need is that the (tiny) Java Virtual Machine (or a browser that has
one inside it) be available, and it can run anywhere, anytime-now and in the future.
With a hybrid Java and native method program, however, you've given up that cross-platform capability. First of all,
Java programs that use native methods cannot be applets. Period. For security reasons, applets cannot load native
code. So if you use native methods, you've just removed the enormous number of users on the World Wide Web from your
market.
Even if you're just creating a Java application, however, and don't intend your code to be run on the Web, using
native methods also negates the capability of your program to run on any platform. Native code is, by definition,
platform specific. The native code must exist on the platform your Java program is running on for that program to
work. For your program to work on different platforms, you'll have to port your native code to that specific
platform-which may not be a trivial task. And as new systems or new versions of operating systems appear, you may
have to update or re-release new versions of that native code for every system. The write-it-once-run-it-everywhere
advantage of Java ceases to exist when you use native methods.
No comments:
Post a Comment