Using a DLL or .so in an applet

[Qu0ll]

I have a 3rd-party JAR which includes code that requires a DLL (or .so on
Linux) to work and I need to use it in a JNLP-launched applet. What's
required?

1. I believe I need to get the DLL inside its own JAR and mark it as a
native library in the JNLP. Is that just a matter of using the jar command
to put it in the JAR?

2. Must the applet then be signed?

3. If yes to (2), will the end user still get some kind of security warning
before running the applet?

4. If yes to (3), will the warning only appear the first time the applet is
run?

5. Do I need to manually "load" the DLL inside the applet's code? If not,
how else does it know where to find the DLL (like -Djava.library.path in an
application)?

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Andrew Thompson]

I have a 3rd-party JAR which includes code that requires a DLL (or .so on
Linux) to work and I need to use it in a JNLP-launched applet.  What's
required?

1. I believe I need to get the DLL inside its own JAR and mark it as a
native library in the JNLP.  Is that just a matter of using the jar command
to put it in the JAR?

Yes. Make sure the native is in the root of the Jar.

2. Must the applet then be signed?

It is more complicated than that. All Jars in the
same JNLP as the natives must be digitally signed,
and by the same cert. That JNLP must also declare
all-permissions. If that JNLP is a component-desc,
then JNLP files of any other security level can use
it.

3. If yes to (2), will the end user still get some kind of security warning
before running the applet?

Yes, before getting all-permissions code into screen,
the user will see a security dialog, even if the main
app. is sand boxed.

4. If yes to (3), will the warning only appear the first time the applet is
run?

It depends. Try one of my apps which uses a self-signed
certificate and the end user gets warned it is not verified,
and the 'always trust' checkbox is not checked. If the cert.
is verified by a CA, the checkbox is usually checked.

5. Do I need to manually "load" the DLL inside the applet's code?  If not,
how else does it know where to find the DLL (like -Djava.library.path in an
application)?

It's something like ..
System.loadLibrary("nativeNameNoExtension");
...but I have not dealt much with natives.

Make sure you put each native into a resources section
specific to the OS. That way, you save each user set
the download of around half the size of the natives
( and Mac. users get a 'super optimized' download .

 

[Qu0ll]

Hi Andrew,

Yes. Make sure the native is in the root of the Jar.

OK, no problems there.

It is more complicated than that. All Jars in the
same JNLP as the natives must be digitally signed,
and by the same cert. That JNLP must also declare
all-permissions. If that JNLP is a component-desc,
then JNLP files of any other security level can use
it.

Can extensions be used where native libraries and JARs are signed by a
different cert from that which I use to sign my applet JAR? They will be in
separate JNLP files. Specifically I will be using the JOGL extension which
includes JARs signed by Sun and my own JNLP which includes JARs signed by
"me".

Yes, before getting all-permissions code into screen,
the user will see a security dialog, even if the main
app. is sand boxed.

Pity :-(

It depends. Try one of my apps which uses a self-signed
certificate and the end user gets warned it is not verified,
and the 'always trust' checkbox is not checked. If the cert.
is verified by a CA, the checkbox is usually checked.

I tried them but they were mostly applications as opposed to true applets
which is what I am dealing with. There should be better terminology for
JNLP "programs". Every time I mention JNLP and applet most people assume
the programs will be running outside the browser. (I am not saying you made
that assumption BTW).

It's something like ..
System.loadLibrary("nativeNameNoExtension");
..but I have not dealt much with natives.

Right, so it's not automatic. Thanks for the info.

Make sure you put each native into a resources section
specific to the OS. That way, you save each user set
the download of around half the size of the natives
( and Mac. users get a 'super optimized' download .

Yes, I am modeling it on the way the JOGL extension works with its natives.
But, I am curious, what do you mean by "super optimised" download for Mac
users? My applet probably won't even work on Macs as they don't have Java 6
Update N (i.e. 6u10+).

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

 

[Roedy Green]

1. I believe I need to get the DLL inside its own JAR and mark it as a
native library in the JNLP. Is that just a matter of using the jar command
to put it in the JAR?

You can do it either way. Your JNLP must mention all the jars.

2. Must the applet then be signed?

yes. JNI always requires signing. It blows the doors off any
security.

3. If yes to (2), will the end user still get some kind of security warning
before running the applet? yes.

4. If yes to (3), will the warning only appear the first time the applet is
run?

The user has the option of installing the cert as trusted.

5. Do I need to manually "load" the DLL inside the applet's code? If not,
how else does it know where to find the DLL (like -Djava.library.path in an
application)?

You need a load or loadLibrary call.
see http://mindprod.com/jgloss/jni.html

Dump the java.library.path system property to see the various places
it will look for the DLL. It is Java Web Start's problem to find a
place to store the DLL and to make it accessible. This is perhaps the
#1 reason to use Java Web Start. Without it, it is very difficult to
find a suitable place on the path to install the DLL and have the
browser notice it, and to select the appropriate code for the given
platform. You may end up writing browser specific code.

see http://mindprod.com/jgloss/javawebstart.html
http://mindprod.com/jgloss/jnlp.html

 

[Roedy Green]

Can extensions be used where native libraries and JARs are signed by a
different cert from that which I use to sign my applet JAR?

All Jars mentioned by a given JNLP file must be signed by the same
cert. The easiest way to do this is to repack any jars signed with
something else. I have never done it, but you can also use multiple
JNLP files and link them together. Each JNLP handles the jars signed
by the same cert.