Discussion:
JNI Feasibility
Tushar
2009-05-12 04:36:09 UTC
Permalink
Hi.....

I am using JNI to interact my application with the C/C++ based
library.

But i want to know regarding the feasibility of using JNI. I want this
things in details.

I searched a lot for this so i collected some points as:


* You can't access arbitrary functions in arbitrary DLLs. JNI
requires that you write a glue C/C++ layer to do whatever you want to
do natively.
* On Android, your glue layer must contain a JNI_OnLoad function
that explicitly register every method that needs to be made available
to the JVM. The JVM can't simply check the export tables and
intelligently import it.
* Since developers must write a glue layer, you must also compile
and package that glue layer per platform you are targeting. This
design is absurd because platforms can have different CPU
architectures and different Operating Systems, and still support
similar calls in the similar libraries.

***** On Android, you must use System.load and provide a full path
instead of using System.loadLibrary. This is because loadLibrary only
checks /system/lib; it does not search LD_LIBRARY_PATH or your current
working directory. Unfortunately, applications can't write to the /
system/lib directory (without root).


IS ANDROID SUGGEST to use JNI for calling native
libraries.... ?????????
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Dianne Hackborn
2009-05-12 06:09:20 UTC
Permalink
Post by Tushar
* Since developers must write a glue layer, you must also compile
and package that glue layer per platform you are targeting. This
design is absurd because platforms can have different CPU
architectures and different Operating Systems, and still support
similar calls in the similar libraries.
Yes, if you are writing native code it will only work on the CPU
architecture(s) you build it for. If you don't like this, don't use native
code. I don't see what this has to do with JNI.
Post by Tushar
***** On Android, you must use System.load and provide a full path
instead of using System.loadLibrary. This is because loadLibrary only
checks /system/lib; it does not search LD_LIBRARY_PATH or your current
working directory. Unfortunately, applications can't write to the /
system/lib directory (without root).
Please look in the android-ndk group if you are wanting to bundle native
code with your app.
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
David Turner
2009-05-12 14:17:14 UTC
Permalink
Post by Tushar
* You can't access arbitrary functions in arbitrary DLLs. JNI
requires that you write a glue C/C++ layer to do whatever you want to
do natively.
Yes.
Post by Tushar
* On Android, your glue layer must contain a JNI_OnLoad function
that explicitly register every method that needs to be made available
to the JVM. The JVM can't simply check the export tables and
intelligently import it.
this is not needed. The first time you try to call a native method from your
application, the VM will look in the current process' address space for a
function maching its JNI name (e.g.
Java_package_name_ClassName_method_name).
Once found, the result is cached, and the function is called.
Post by Tushar
* Since developers must write a glue layer, you must also compile
and package that glue layer per platform you are targeting. This
design is absurd because platforms can have different CPU
architectures and different Operating Systems, and still support
similar calls in the similar libraries.
similar != always the same, for a lot of reasons (e.g. alignment issues,
parameter
passing conventions, etc...)

you're looking for something that is, I believe, called "JNA". Unfortunately
this is not
implemented by Dalvik because it has some "interesting" performance and
interoperability issues.

Finally, nearly all native system libraries are unstable in Android, which
means that
any program that would attempt to call them directly would have some issues
with
the next off-the-air update.

Which is also why we're preparing an Android Native Development Kit (NDK)
which
will provide a set of stable APIs/ABIs your native code will be able to rely
on.
Post by Tushar
***** On Android, you must use System.load and provide a full path
instead of using System.loadLibrary. This is because loadLibrary only
checks /system/lib; it does not search LD_LIBRARY_PATH or your current
working directory. Unfortunately, applications can't write to the /
system/lib directory (without root).
IS ANDROID SUGGEST to use JNI for calling native
libraries.... ?????????
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tomei Ningen
2009-05-13 00:41:44 UTC
Permalink
I think the original poster's question is:

If I want to call a native function (in libc, etc) that's known to exist on
all platforms with the same name and same parameters -- is there a way to do
this without writing a JNI function which would tie me to a particular
CPU/OS combo

I think the answer is no, but that may be worth having ....
Post by David Turner
Post by Tushar
* You can't access arbitrary functions in arbitrary DLLs. JNI
requires that you write a glue C/C++ layer to do whatever you want to
do natively.
Yes.
Post by Tushar
* On Android, your glue layer must contain a JNI_OnLoad function
that explicitly register every method that needs to be made available
to the JVM. The JVM can't simply check the export tables and
intelligently import it.
this is not needed. The first time you try to call a native method from your
application, the VM will look in the current process' address space for a
function maching its JNI name (e.g.
Java_package_name_ClassName_method_name).
Once found, the result is cached, and the function is called.
Post by Tushar
* Since developers must write a glue layer, you must also compile
and package that glue layer per platform you are targeting. This
design is absurd because platforms can have different CPU
architectures and different Operating Systems, and still support
similar calls in the similar libraries.
similar != always the same, for a lot of reasons (e.g. alignment issues,
parameter
passing conventions, etc...)
you're looking for something that is, I believe, called "JNA".
Unfortunately this is not
implemented by Dalvik because it has some "interesting" performance and
interoperability issues.
Finally, nearly all native system libraries are unstable in Android, which
means that
any program that would attempt to call them directly would have some issues
with
the next off-the-air update.
Which is also why we're preparing an Android Native Development Kit (NDK)
which
will provide a set of stable APIs/ABIs your native code will be able to
rely on.
Post by Tushar
***** On Android, you must use System.load and provide a full path
instead of using System.loadLibrary. This is because loadLibrary only
checks /system/lib; it does not search LD_LIBRARY_PATH or your current
working directory. Unfortunately, applications can't write to the /
system/lib directory (without root).
IS ANDROID SUGGEST to use JNI for calling native
libraries.... ?????????
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
fadden
2009-05-13 01:23:30 UTC
Permalink
Post by Tomei Ningen
If I want to call a native function (in libc, etc) that's known to exist on
all platforms with the same name and same parameters -- is there a way to do
this without writing a JNI function which would tie me to a particular
CPU/OS combo
I think the answer is no, but that may be worth having ....
The answer to, "can I just call a libc function directly from Java
code without writing an intermediate function" is "no". For one
thing, JNI functions always take a JNIEnv pointer as the first
argument, which hardly anything is going to expect.

As far as being tied to a particular CPU/OS combo: the C source code
can be portable, but it must be compiled in a target-specific way. So
you can have one set of sources for multiple platforms, but it needs
to be compiled into native code.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tushar
2009-05-13 04:46:08 UTC
Permalink
Hi..

One point i noticed is.. If we use JNI then execution speed
will get increase ??

How we can prove this point ... ??
Is it possible to check this practically ??
Means if i write a android application with some business logic n i
will check the CPU hit count and same application with JNI support in
which my native code will take care of the business logic ... ???


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Dianne Hackborn
2009-05-13 05:26:32 UTC
Permalink
Unless there is something you need to do that you can't in Java, don't use
JNI.
Post by Tushar
Hi..
One point i noticed is.. If we use JNI then execution speed
will get increase ??
How we can prove this point ... ??
Is it possible to check this practically ??
Means if i write a android application with some business logic n i
will check the CPU hit count and same application with JNI support in
which my native code will take care of the business logic ... ???
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tushar
2009-05-13 12:55:39 UTC
Permalink
Hi,
Can any one let me know how i can say that JNI application is gonna
give faster execution..

Please let me know with detailed ans..
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Thiago Rafael Becker
2009-05-13 13:13:47 UTC
Permalink
It depends on what you're doing. No one can tell you if Java or JNI
will perform better. A good starting point to know why this is this
way is watching the "Dalvik internals" video in the Google I/O 2008

Hi,
  Can any one let me know how i can say that JNI application is gonna
give faster execution..
Please let me know with detailed ans..
--
Thiago Rafael Becker
http://www.monstros.org/trbecker

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Dianne Hackborn
2009-05-13 16:47:18 UTC
Permalink
Again: unless you have specific performance problems in your app, don't use
JNI. Using native code is going to require a lot more effort on your part,
be harder to maintain since crashes and other problems in native code are
harder to deal with, in the future reduce the number of devices your app
runs on, and will probably result in a more unstable program as you make
mistakes in the native code like memory corruption that would not normally
be a problem in Java.
Post by Tushar
Hi,
Can any one let me know how i can say that JNI application is gonna
give faster execution..
Please let me know with detailed ans..
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tushar
2009-05-13 04:47:55 UTC
Permalink
What about the data types which i am gonna pass thro the native
function whcih i am calling from my java code. ??

For exaple if the funcn takes one char* as a parameter and if i pass
the String which is a class in Java ..Will this create some issue ??
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tomei Ningen
2009-05-13 17:47:24 UTC
Permalink
What about exposing dlopen, dlsym, etc, to Java programs?

int handle = android.Unix.dlopen("/lib/libc.so");
int open = android.Unix.dlsym(handle, "open");
int fd = android.NativeCaller.call(open, "/etc/passwd");

Some marshalling would be nice to pass Strings easily to the C code, but
otherwise all the parameters could just be ints. Handling structs would be a
little pain but not entirely impossible, though you have to worry abut
different field offsets on different platforms that it also limits
portability ....
Post by fadden
Post by Tomei Ningen
If I want to call a native function (in libc, etc) that's known to exist
on
Post by Tomei Ningen
all platforms with the same name and same parameters -- is there a way to
do
Post by Tomei Ningen
this without writing a JNI function which would tie me to a particular
CPU/OS combo
I think the answer is no, but that may be worth having ....
The answer to, "can I just call a libc function directly from Java
code without writing an intermediate function" is "no". For one
thing, JNI functions always take a JNIEnv pointer as the first
argument, which hardly anything is going to expect.
As far as being tied to a particular CPU/OS combo: the C source code
can be portable, but it must be compiled in a target-specific way. So
you can have one set of sources for multiple platforms, but it needs
to be compiled into native code.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Dianne Hackborn
2009-05-13 18:02:07 UTC
Permalink
That seems horribly dangerous to me, since there are many functions in the
standard libraries that are not in the officially supported NDK headers, so
it would be easy to use things that would break in the future.

Also, what would the actual utitilty of this be? The example you show is
not really reasonable, since you can do the exact same thing, easier, with
the Java APIs.

Seriously, if you want to use native APIs, write your native code that does
it. I think that mixing these into regular Java code is a super bad idea.
Post by Tomei Ningen
What about exposing dlopen, dlsym, etc, to Java programs?
int handle = android.Unix.dlopen("/lib/libc.so");
int open = android.Unix.dlsym(handle, "open");
int fd = android.NativeCaller.call(open, "/etc/passwd");
Some marshalling would be nice to pass Strings easily to the C code, but
otherwise all the parameters could just be ints. Handling structs would be a
little pain but not entirely impossible, though you have to worry abut
different field offsets on different platforms that it also limits
portability ....
Post by fadden
Post by Tomei Ningen
If I want to call a native function (in libc, etc) that's known to exist
on
Post by Tomei Ningen
all platforms with the same name and same parameters -- is there a way
to do
Post by Tomei Ningen
this without writing a JNI function which would tie me to a particular
CPU/OS combo
I think the answer is no, but that may be worth having ....
The answer to, "can I just call a libc function directly from Java
code without writing an intermediate function" is "no". For one
thing, JNI functions always take a JNIEnv pointer as the first
argument, which hardly anything is going to expect.
As far as being tied to a particular CPU/OS combo: the C source code
can be portable, but it must be compiled in a target-specific way. So
you can have one set of sources for multiple platforms, but it needs
to be compiled into native code.
--
Dianne Hackborn
Android framework engineer
hackbod-***@public.gmane.org

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---
Tushar
2009-05-26 12:34:36 UTC
Permalink
hi all,

I am creating Benchmark study report for JNI.
I am writing some sample codes for creating the report..I am
considering following test cases for this ...

Test cases :

1) Call to a method only in Java and Call to a method in native code
thro JNI
2) Call to a method with parameters only in Java and Call to a method
wiht parameters in native code thro JNI
3) Parameters of different types and size and number of arguments.
4) Calling methods of types :

1) Simple method
2) Trivial Operation
3) Computaional Operation(Such as encryption decryption)

For all this purpose i will check the CPU hits, CPU time taken for the
method execution,memory used .

So can any one have knowledge that how i can get this values in my
code.

I have used just used System.nanoTime() at the start and end of the
method . but is it a proper approach.

for example :
1) Only java call :
Log.i("JNI","****************** Start time : "+System.nanoTime
());
double res = 0.5;
for (int i=0; i < 1000000; i++)
{
res = (res * i) / 3.1415926;
res = StrictMath.sin(res);
res = StrictMath.cos(res);
res = StrictMath.sqrt(res) * 3.1415926;
}
Log.i("JNI","****************** Stop time : "+System.nanoTime
());

2) JNI Call
Log.i("JNI","****************** Start time : "+System.nanoTime
());
JNIclass.jnimethod(); // Above logic but in native code
Log.i("JNI","****************** Stop time : "+System.nanoTime
());

Let me know how i can get more info on getting all this values n t\let
me know is this approach is rite
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-platform-/***@public.gmane.org
To unsubscribe from this group, send email to android-platform+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en
-~----------~----~----~----~------~----~------~--~---

Loading...