size of extracted jna files and other sensor applet info

[Scott Cytacki]

We are working on moving the goio java support to use JNA instead of JNI.

This is to make it easier to maintain and incrementally add support for stuff in the goio sdk.  

There is some concern about how JNA would add size to the java library interfacing the goio sdk.

Here is some analysis of that:

If your downloading code is smart and it knows the arch and it can handle gzip then the 

overhead of jna is pretty small ~30k:

Here are the sizes for OSX of the native libraries.  

-rw-r--r--@ 1 scytacki  admin    91K Jul 19 09:17 libjnidispatch.jnilib.gz

-rw-r--r--  1 scytacki  admin    29K Aug 20 11:10 libjnidispatch.jnilib.i386.gz

-rw-r--r--  1 scytacki  admin    30K Aug 20 11:10 libjnidispatch.jnilib.ppc7400.gz

-rw-r--r--  1 scytacki  admin    31K Aug 20 11:10 libjnidispatch.jnilib.x86_64.gz

Here is one command I used to extract the arch from the os x universal file:

lipo -extract i386 libjnidispatch.jnilib -output libjnidispatch.jnilib.i386

However the JNA java files are still rather large:

-rw-r--r--  1 scytacki  admin   126K Aug 20 11:17 ../jna-java.jar

So in conclusion it is probably lighter to use JNI than JNA.  However it is more work to maintain.

It is possible that some of the JNA classes can be removed to reduce the size however none of them are particularly large.

We can try to use a tool like http://proguard.sourceforge.net/ to remove all the classes and methods that are not used.

I'd estimate this would at most reduce the size to 50%, but that might be optimistic.

Another alternative is to use pack200.  Using that the jna-java jar gets down to:

40k.

Because pack200 is only supported in the new java plugin which I think only a few people will have, we would need to work around this.

The best way I can think of that will take advantage of caching.  Is to wrap the pack200 file in another jar file.  And that other jar file unpacks it.  Java has included the pack200 uncompressor in its API since java 1.5, so we should be able to count on this.

Making sure that the applets cache resources is important so the java code doesn't download the nativelib and any dynamic jars everytime.   The current sensor applet doesn't do this, so it actually downloads most of the files each time.  Hopefully it is possible to use java's getResource call as documented here: http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html#ClassLoader_and_Resources

I believe that can be used to reference resource relative to the applets codebase and have them be cached.

Alternatively we might be able to use dynamic applet tags.  That approach is something we should explore anyhow so that the loading of the applet and the acceptance of the signature isn't required until it is actually needed.

Scott