This is documentation for Mathematica 5, which was
based on an earlier version of the Wolfram Language.
View current documentation (Version 11.1)

Documentation / Mathematica / Add-ons & Links / J/Link / Part 2. Writing Java Programs That Use Mathematica /

2.18 Writing Applets

This User Guide has presented a lot of information about how to use J/Link to enable MathLink functionality in Java programs, whether those Java programs are applications, JavaBeans, servlets, applets, or anything else. If you want to write an applet that makes use of a local Mathematica kernel, you have some special considerations because you will need to escape the Java security "sandbox" within which the browser runs applets.

The only thing that J/Link needs special browser security permission for is to load the J/Link native library. The only reason the native library is required, or even exists at all, is to perform the translation between Java calls in the NativeLink class and Wolfram Research's platform-dependent MathLink library. NativeLink is the class that implements the MathLink interface in terms of native methods. Currently, every time you call MathLinkFactory.createMathLink() or MathLinkFactory.createKernelLink(), an instance of the NativeLink class is created, so the J/Link native library must be loaded. In other words, the only thing in J/Link that needs the native library is the NativeLink class, but currently all MathLink or KernelLink objects use a NativeLink object. You cannot do anything with J/Link without requiring the native library to be loaded.

Different browsers have different requirements for allowing applets to load native libraries. In many cases, the applet must be "signed," and the browser must have certain settings enabled. Note that letting Java applets launch local kernels is an extreme breach of security, since Mathematica can read sensitive files, delete files, and so on. It is probably not a very good idea in general for users to allow applets to blast such an enormous hole in their browser's security sandbox. A better choice is to have Java applets use a kernel residing on the server. In this scenario, the browser's Java runtime does not need to load any local native libraries, so there are no security issues to overcome. This requires significant support on both the client and server side. This support is not part of J/Link itself, but it is a good example of the sort of programs J/Link can be used to create.