Restrictions

There are no restrictions imposed by DSJ on your Java applications. Once the resources are downloaded to the client machine, there are no functional differences from an application that is installed locally through more traditional means.

Considerations

When developing applications that will be deployed with DSJ, you should take into account the following:

Command line arguments

The DSJ client takes its own command line arguments. When the client encounters any properties it recognizes, it removes them from the command line. The arguments that are left are passed on the to application.

These client-side properties are all prefixed with the letters "DSJ", so it is unlikely that they will conflict with any arguments used by your application.

External files

If your application uses external files, such as image files, data files, or DLLs for native methods, DSJ provides a way to download these files to the client before the application begins. You can download these files to an absolute file location on the client machine, or a location that is relative to the current directory of the DSJ client.

Fetching URL contents

Because the client may load resources on-demand over a network connection, you should not assume that the contents of a URL are immediately available.

For example, you could use ImageLoader.waitForImage( ) (ImageLoader is part of JBCL):

Object x = someFunc();
URL u = x.getClass().getClassLoader().getResource(resName);
Image i = u.getContent();
ImageLoader.waitForImage(this, i);
setImage(i);

URL Factory

The DSJ client normally assigns its class loader as the URL factory by calling URL.setURLStreamHandlerFactory( ). If you want to assign your own URL factory, you must set the hidden client property DSJUseURLFactory to false, either in the clientÆs dsj.properties file, or on the command line. This causes DSJ to register its URL handler with the default mechanism instead, by adding the "jax" protocol to the list of recognized protocols stored in the system property java.protocol.handler.pkgs.

Then, in order for this secondary approach to work, the dsjclient1.0.jar file must be listed on the applicationÆs class path so that it may be accessed by the system class loader. But having the dsjclient1.0.jar file accessed by the system class loader prevents the file from being updated.

Therefore, if you use your own URL factory for a particular application, you cannot have the server remotely update the client when their versions are not in sync; if that needs to be done, the application will not run. (You could run another application from the same server that did not use its own URL factory. That would update the client; then you could run the first application.)

The DSJ background cache-write thread

The DSJ client writes its cache using a minimum-priority thread, which is always active.

Using your own custom class loader

If you use your own custom class loader, you must interact with the DSJ class loader to download classes from a DSJ server.