Add Kernel and JNI build support for Applets and JNLP JWS

[GoogleCodeExporter]

I have successfully completed work implementing Aparapi in an Applet + JNLP 
environment. This required a few small changes to the Aparapi source code and 
build scripts.

In summary:

- Added support for sun.jnlp.applet.launcher in Kernel
- Added support for org.jdesktop.applet.util.JNLPAppletLauncher in Kernel
- Changed build.xml to output .jnilib files in appropriate /dist directories 
instead of platform specific binaries (.so, .dll, .dylib) dropped in the root 
folder


Once I complete preparation of the Applet+JNLP Eclipse projects I will work on 
checking those in under separate issue requests.

Original issue reported on code.google.com by [email protected] on 11 Feb 2012 at 12:15

Attachments:

• patch.txt

[GoogleCodeExporter]

Ryan thanks for this patch.  I think being able to execute Aparapi apps via 
JNLP would be very useful. 

I do have a question (my lack of JNLP knowledge sadly).  Could you tell me what 
the purpose of   "private static void loadLibraryInternal(String _libraryName)" 
which we introduce into Kernel.java.  Who calls this?  Is this introspected by 
JNLP?  Would it be possible to move this to another class?  or does it have to 
co-exist in the class that loads a native library?

I see a lot of deltas in this patch which seems to be the result of whitespace 
changes (granted I am applying after merging LocalMemory and Multi-Dim ;) so I 
may have exacerbated this).

Assuming you are using eclipse, would you consider applying the formatting 
rules from  the root aparapi directory (aparapi-eclipseformatting.xml) this can 
be imported via preferences->Java->Code Style->Formatter. This will help me 
review the patch.

Gary

Original comment by [email protected] on 14 Feb 2012 at 5:28

• Changed state: Accepted

[GoogleCodeExporter]

The loadLibraryInternal method is called in the Kernel static block and is 
required to be used whenever a native library is loaded inside of an applet 
using JNLP, as a direct replacement for System.loadLibrary (see links below). 
As mentioned in the Javadoc included in the patch, the applet code external to 
Aparapi supplies applet-launcher.jar from 
http://java.net/projects/applet-launcher/sources/svn/show/trunk?rev=44 and the 
method which needs to be invoked by any code loading a native library is 
described in detail at http://jogamp.org/applet-launcher/www/.  The method is 
non-intrusive and if it doesn't find applet-launcher in the classpath it falls 
back to System.loadLibrary. The only alternative would be to have Aparapi check 
whether all of its required libraries have already been loaded into its 
respective classloader and avoid trying to load them twice, which results in an 
error. Then the loadLibraryInternal method could potentially be put into the 
code outside of Aparapi (this path has not been tested). I put the method in 
the Kernel class because I was not sure I could always guarantee that if the 
Aparapi native libraries were loaded external to Aparapi that all classes would 
be in the same classloader as Aparapi. But on second thought, if this is an 
applet that should be the case. 

The required patch changes to build.xml and Subversion are required in either 
case, as the applet-launcher has specific jar suffix requirements to load JNI 
based code (which does follow standard naming conventions).

Original comment by [email protected] on 15 Feb 2012 at 4:16

[GoogleCodeExporter]

I will try to re-submit a patch this morning with the required formatting. I 
have reverted my workspace after yesterday's updates, so I will be re-applying 
my own patch.

Original comment by [email protected] on 15 Feb 2012 at 4:18

[GoogleCodeExporter]

Thanks for the explanation, that helps me a lot.

Sorry for causing the extra work regarding formatting. I have a bunch of 
workspaces dotted around, I think one criticism of Eclipse (which generally I 
love) is it's handling of workspaces.  For each branch I find I have to have a 
separate workspace and it is a pain.  

Once I get your patch (and fix the regression bug that Kenneth found) I will 
take a look at this again. 

Thanks.   

Original comment by [email protected] on 15 Feb 2012 at 4:24

[GoogleCodeExporter]

I just realized that Eclipse does not show you nor automatically apply any 
patches to a workspace's Subversion configuration :( So whenever you use my 
patches and I describe Subversion updates in the issue ticket, you will have to 
merge those in manually using your favorite Subversion plugin. Bummer.

Original comment by [email protected] on 15 Feb 2012 at 5:34

[GoogleCodeExporter]

Yes, Eclipse workspaces are a pain, especially when you have to force quit 
Eclipse and they get corrupted. And the Eclipse merge tool being really picky 
about whitespace is also a pain.

As a note, if you are concerned about Kernel having the loadLibraryInternal 
method then maybe we could use some code similar to 
http://stackoverflow.com/questions/1007861/how-do-i-get-a-list-of-jni-libraries-
which-are-loaded/1008631 to try and verify explicitly that the Aparapi native 
libraries have or have not already been loaded. Either way, having that kind of 
code could be great for debugging purposes in general.

I'll try moving the loadLibraryInternal code into the applet and out of the 
kernel to see if it still works.

Original comment by [email protected] on 15 Feb 2012 at 5:42

[GoogleCodeExporter]

I'm having some trouble with my workspace...for now, let's just remove the 
loadLibraryInternal method and patch the build.xml and Subversion repository 
information for the com.amd.aparapi.jni project. This will at least give us 
.jnilib native libraries per platform and an organized build artifact tree.

Here is the Subversion changes needed (basically ignore the new /dist folder 
tree):

Modified: svn:ignore
   - aparapi.lib

aparapi.exp

aparapi.obj

aparapi_x86.dll

include

   + aparapi.lib
aparapi.exp
aparapi.obj
aparapi_x86.dll
include
dist

Original comment by [email protected] on 15 Feb 2012 at 8:05

Attachments:

• patch.txt

[GoogleCodeExporter]

I've checked in the submitted build.xml and SVN updates. I'd like to leave this 
issue open until we decide how to proceed with the JNLP-specific code changes 
to the Kernel class. I've tried loading the native libraries external to 
Aparapi in an applet without success.

I can add the necessary Kernel changes, test the functionality again and 
check-in the changes. Also, we could consider including the applet-launcher jar 
with the Aparapi distribution, the license appears to be BSD 
http://java.net/projects/applet-launcher (Source License: BSD) and 
http://java.net/projects/applet-launcher/sources/svn/content/trunk/LICENSE.txt?r
ev=44

Original comment by [email protected] on 19 Feb 2012 at 1:00

[GoogleCodeExporter]

Original comment by [email protected] on 19 Feb 2012 at 1:00

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by [email protected] on 19 Feb 2012 at 1:01

[GoogleCodeExporter]

Issue 31 has been merged into this issue.

Original comment by [email protected] on 19 Feb 2012 at 1:03

[GoogleCodeExporter]

In order to facilitate the usage of JNLP it would be desirable to introduce the 
following changes:

1) Change all platform specific JNI library suffixes to .jnilib

2) Introduce additional information to the JNI library names to avoid naming 
collisions in the /dist folder. For example, change 
aparapi_${x86_or_x86_64}.dll to aparapi_${os.name}_${x86_or_x86_64}.jnilib

3) In Kernel add the additional naming information to the loadLibrary call. For 
example, change libName = "aparapi_x86_64" to libName = "aparapi_" + 
System.getProperty("os.name") + "_x86_64"

4) Re-introduce the loadLibraryInternal method to support the applet-launcher 
jar

5) Include the applet-launcher jar in the source tree

6) Include an example applet and dynamic web project, complete with Ant scripts 
to demonstrate the functionality


This is all pretty straightforward and already in a completed form in my local 
workspace. But since it appears that there are some major changes occurring in 
a branch right now, I want to know when the best time would be to merge in my 
changes.

Original comment by [email protected] on 3 Mar 2012 at 4:13

[GoogleCodeExporter]

Ryan

Yes I am tearing up the JNI tree a little in the extensions branch, so I would 
suggest holding off for perhaps a week.  Mostly the changes to the existing 
API's are just cosmetic, but they would be hard to track.  I need to make some 
of the kernelrunner code re-usable and so want to restructure in a more natural 
form. 

I will let let you know when I merge the changes and then promise to wait ;) 
for you to put in these changes.  Apologies for the delay. 

BTW when we are done, here is how you will be able to add your own OpenCL code. 

You first define an interface with OpenCL annotations..

 interface Squarer extends OpenCLBinding<Squarer>{
      @Kernel("{\n"//
            + "  const size_t id = get_global_id(0);\n"//
            + "  out[id] = in[id]*in[id];\n"//
            + "}\n")//
      public Squarer square(//
            Range _range,//
            @GlobalReadOnly("in") float[] in,//
            @GlobalWriteOnly("out") float[] out);
   }

Then you 'realize' the interface
  Squarer squarer = Device.firstGPU(Squarer.class);

Now you can call it ;)
  squarer.square(Range.create(in.length), in, out);

I think that we will have the easiest OpenCL binding out there...

;)

Original comment by [email protected] on 4 Mar 2012 at 4:45

[GoogleCodeExporter]

How would we like to handle bundled license-compatible third party code going 
forward? Specifically, I've been thinking about including applet-launcher in 
either binary or source form.

My only concern with simply listing it as a dependency in order to make 
applets/jnlp work is if the jar ever disappears...of course, the chance of that 
happening is low, especially since JOGL, etc. uses it heavily but I thought I'd 
ask.

Original comment by [email protected] on 6 Mar 2012 at 5:27