Saving a resource on a client--best practices question

[Phil Freihofner]

I have an Applet with some compressed sound files included as "resources." I've written a decoder that converts these compressed files (OggVorbis) to .wav format files. I'd like to save these in some sort of "temp" folder on the client. The .wav files play much quicker and use less resources than the compressed OggVorbis files, and I would very much prefer the .wav option.

Is there a standard plan or plans as to how to go about this?

1) Is JNLP absolutely needed in this situation, or are there possibly some default or restricted areas where one is allowed to store a file? (I'm thinking, as I write this, JNLP is going to be required.)

2) Is there a standard, preferred folder for writing temporary content? It might be nice if on subsequent visits the code could check to see if the files are still present rather than decode them anew with each visit to the website. But every OS will be different, so I'm wondering if there is a "designated" temp area that can be determined. I'd prefer to leave this operation in the background if possible. Of course, there will be the JNLP signoff.

Thanks for any help!! This has been a considerable challenge figuring all this out. I only got JNLP working for the first time last week, and just this evening finally found a reference to a document that explains how one can go to one's Control Panel->Java settings (I'm on Windows XP-Home) to select "Show console". So, now, I can finally view System.out.println() statements and stack dumps. (I spent a LOT of time looking for settings on the browsers themselves to enable Java console viewing. Wrong!)

[Ulf Dittmer]

You don't need JNLP, but the applet would need to be signed in order to access the client file system.

Are compressed WAV files that much bigger than compressed OGG files to make that worthwhile, though?

[James Sabre]

I'm wondering why you are not performing off-line conversion of the OGG files to WAV files and including the WAV files as the resource rather than the OGG files.

There are two place one can pretty much be guaranteed to be able to write to - System.getProperty("user.home") and System.getProperty("java.io.tmpdir"). Since one can't be sure that the content of "java.io.tmpdir" remain after a system re-boot then I normally use a subdirectory of "user.home. When I do have to save stuff on the client I use the directory System.getProperty("user.home") + "/my-program-name" .

[Phil Freihofner]

Thank you both for your helpful information!

I will take a closer look at the signing option, and try to give some good consideration to the pros and cons vs JNLP.

Thank you for the handles to areas on the client. I was afraid that each OS would require something different, or each browser. So, System.properties is full of good stuff. I'll spend some time getting better acquainted with that, too.
[EDIT: Just spotted the following tutorial: Properties]

As to the size of the files, I can give you an example. One cue I wish to use is close to 30 seconds long. As a .wav, it is 4,800 KB. As a decent sounding OggVorbis compressed file, it is 279 KB. So, as you can see, I'm looking at better than 10:1 savings. My first draft of a puzzle game with lots of sound cues currently takes about three minutes to download, with is too much for a "casual" web applet game. Over 95% of that bulk was .wav files. So I think what I'm attempting to do is a reasonable plan (given the "unreasonableness" of the amount of sound I wish to employ).

[john price]

Signing Applets was a pain in the butt. Found this program today that does it for you :

http://download.cnet.com/JAR-Maker/3000-2213_4-10588876.html

It can make JAR files, sign JAR files, make Keystores, turn them into .exe files (I think), WebStart JLNP, and Applet HTML.

It's very simple to do.

Here is a youtube video explaining exactly what to do :

http://www.youtube.com/watch?v=FhoX8RbJeZs

I make the JAR files through command line and then sign them through the program. I usually make the keystore file myself too. I couldn't get signed JAR files working on the command line though. Too complex for me (spent hours trying to figure it out).

Anyway, cheers ,
cc11rocks

[Phil Freihofner]

Cheers John!

I came to the conclusion I need to use signing, since JNLP only allows access via a window for every file you want to save or load. I don't want to make the User have to go through this for the multiple sound files.

Finding documentation on Signing has been tricky. Links I found via the JavaTutorials were kind of terse, basically they let you know the tool exists, and one can certainly run it and get a help dump.

However, via Bing, I found this URL with actual explainations and examples (yay handholding!) and thought I'd pass it on:
keytool - Key and Certificate Management Tool

I misused the http syntax on my link to the "Properties" documentation in an above reply. Here it is again:
Properties - The Java Tutorials

On that page there is a link to System Properties on this page that has things like the User.home directory and other useful locations.

(This time I tested the links in the "preview" mode.)

[James Sabre]

Phil Freihofner wrote:

I came to the conclusion I need to use signing, since JNLP only allows access via a window for every file you want to save or load. I don't want to make the User have to go through this for the multiple sound files.

False. A signed JNLP application has exactly the same permissions as the same application run from the command line. It most definitely does not require "... allows access via a window for every file you want to save or load".

I would be interested to know where you obtained this false information from.

P.S. Signing a jar using the command line is very easy. I don't understand why you and others find it difficult. If you want to make it very very very easy then use Ant.

[Phil Freihofner]

I apologize for putting wrong or unclear info on this thread! All my info comes from reading the Java Tutorials (Deployment section->Doing more with Java Rich Internet Applications->JNLP API->Accessing the Client Using JNLP). File access is granted via the FileHandler class. And both the open and save methods invoke a dialog box:

The open method of the FileHandler class invokes the openFileDialog method of the FileOpenService class to display a file chooser.

And this is in addition to the security dialog that comes up. As I am saving numerous .wav files, then reading each one multiple times (each instance invoking the file chooser dialog, if I understand the above correctly), I believe the best course is to use a File object, which in turn requires Signing the Jar. Do correct me again if I still have this wrong!

As for Signing being "difficult," I'm not sure I'm ready to say that, but finding a tutorial with an example (listed above) was kind of tricky. From "Doing More with Java Rich Internet Applications" there is a link to "Signing and Verifying Jar Files". The "Signing Jar Files" subpage says "you must first have a private key" triggering another mental stack push. There IS a bit of conceptual explanation right there, but no link to documentation for this utility in this paragraph. One must find the "Summary of Security Tools" link at the bottom. I found the explanations on its page rather terse. The -help dump provided by the utility itself is excellent. I just prefer to get a little more context and an example, if such exists, when dealing with an unfamiliar function. I also thought John or others following might find this article useful.

The Java Tutorials are a fantastic resource. I feel like I should only be grateful for their existence, not quibble with the presentation here and there.

[James Sabre]

Phil Freihofner wrote:I apologize for putting wrong or unclear info on this thread! All my info comes from reading the Java Tutorials (Deployment section->Doing more with Java Rich Internet Applications->JNLP API->Accessing the Client Using JNLP). File access is granted via the FileHandler class. And both the open and save methods invoke a dialog box:

Before JDK1.7, file access uses the java.io.File class, the File streams, RandomAccessFile etc. JDK1.7 adds some extra classes to deal with files but these do not really help with what you are doing. Programs that are executed though JNLP with all permissions specified in the JNLP file and all jars signed can access files using the classes in package java.io. The standard distribution class java.util.logging.FileHandler has little if anything to do with what you want to do so I assume you are talking of some third party FileHandler class. You don't need it. Don't use it.

The open method of the FileHandler class invokes the openFileDialog method of the FileOpenService class to display a file chooser.

Whatever this FileHandler class does, you don't need it. Just use the classes in the java.io package.

And this is in addition to the security dialog that comes up. As I am saving numerous .wav files, then reading each one multiple times (each instance invoking the file chooser dialog, if I understand the above correctly), I believe the best course is to use a File object, which in turn requires Signing the Jar. Do correct me again if I still have this wrong!

You will get the security dialog when the application is launched via JNLP. Once launched you will only get dialogs if YOU choose to ask the user something or notify him of something. Opening a File using the classes in java.io will not bring up a dialog. I say again - opening a File using the classes in java.io will not bring up a dialog.

As for Signing being "difficult," I'm not sure I'm ready to say that, but finding a tutorial with an example (listed above) was kind of tricky. From "Doing More with Java Rich Internet Applications" there is a link to "Signing and Verifying Jar Files". The "Signing Jar Files" subpage says "you must first have a private key" triggering another mental stack push. There IS a bit of conceptual explanation right there, but no link to documentation for this utility in this paragraph. One must find the "Summary of Security Tools" link at the bottom. I found the explanations on its page rather terse. The -help dump provided by the utility itself is excellent. I just prefer to get a little more context and an example, if such exists, when dealing with an unfamiliar function. I also thought John or others following might find this article useful.

The basics of jar signing are well explained in the short tutorial http://download.oracle.com/javase/tutorial/deployment/jar/signing.html and in http://download.oracle.com/javase/6/docs/technotes/guides/plugin/developer_guide/rsa_signing.html . Google will find you many many examples of how to create an RSA key pair and certificate; this one http://www.exampledepot.com/egs/java.security.cert/CreateCert.html seems pretty complete.

Most of these tutorials do not explain what signing means and assume that the reader understands signing. For this you will need to spend time with Google or a book such as "Beginning Cryptography with Java" by David Hook.

The Java Tutorials are a fantastic resource. I feel like I should only be grateful for their existence, not quibble with the presentation here and there.

One last time - I don't know where you got it from but you do not need to use class FileHandler.

[Paul Clapham]

I have to say, when I first had to sign an applet, I didn't find the tutorial about applet-signing all that easy to understand. The main problem is that it had a whole list of vague-sounding undefined terms which I had to disregard until I had gone through the tutorial a couple of times. Actually that's a conceptual problem I have with the whole field of security and cryptography, if you don't understand why the designers are making you jump through those hoops, you're not going to do a good job of hoop-jumping.

The other problem is that signing an applet isn't something you do every day, so when you come back to redo it two years later you probably will have forgotten what you did and where you put your keystore.

As for those special JNLP things like FileHandler, that was another thing I couldn't understand the purpose of, again most likely because security is one of those things to be swept under the rug as expeditiously as possible. So I just ignored them and wrote ordinary Java code and had no problems at all.

[Phil Freihofner]

@James
I could kick myself. I went through the path I gave you in my previous email, and checked the "FileHandler" link there in the Java Tutorial (http://download.oracle.com/javase/tutorial/deployment/doingMoreWithRIA/usingJNLPAPI.html), and it turned out to be an example program rather than a library class. The classes I should have cited were the following:

  javax.jnlp.FileOpenService;
  javax.jnlp.FileSaveService;
  javax.jnlp.FileContents;

Sorry for the confusion. ("...I don't know where you got it from...")

Thanks for the additional links. The one I posted earlier titled 'keytool - Key and Certificate Management Tool" is quite good, too. I was able to make a keystore easily with its guidance.