I've been playing with Pack200, the new compression technology for Java Web Started applications. And it's just excellent... but insane.

Pack 200 is excellent...

I want to build a Java Web Start demo using the NetBeans Editor Library. The demo will be an example on how to use this excellent library to build powerful text editors in Swing applications, with syntax highlighting.

And, you know, you have to bundle different NetBeans libraries (I needed org-netbeans-modules-editor-fold.jar, org-netbeans-modules-editor-lib.jar, org-netbeans-editor-util.jar and org-openide-util.jar).

These are not really a lot of libraries, but they sum up 2.228 Mb (including my application). That's probably a lot of bytes to transfer for a Java Web Start application.

So I decided to use the new Pack200 technology (bundled with your JDK5) to try to reduce the size of those files.

And in fact it did: those four libraries (and my application) consume now a total of 355 kylobytes, this is, 0.355 Mb.

Now, that is what I call compression!!.

By the way, if you want to get started with Pack 200, then Sun has an excellent guide to get started.

... needed signing ...

I also needed code signing (because org-openide-util needs it because it accesses some system properties).

Since I own one of those Thawte's Free Email Certificates from the Thawte's Web of Trust, I decided to explore if I could sign the code with that certificate. This is a good choice, because Thawte's Web of Trust CA certificate is bundled within the JRE and JDK, and then your signature will be trusted by the platform (although the user will also want to validate your signature, of course). If you create your own test certificate, then the platform will recognize that is has been generated by you (a non trusted CA) and will also warn the user about this.

After some Googling, I found a nice tutorial by Richard Dallaway that clearly explains how to get your digital signing certificate from Thawte and got it working (I'm glad I decided to join Thawte's Web of Trust).

... but Pack 200 is insane

The problem arised when I tried to serve those "Pack 200" files in my server. I don't have a Java-enabled web server (well, not yet! ;-)) so I could not deploy the Pack 200 servlet that comes bundled in the JDK (see your JDK "samples/jnlp/servlet" for more info).

What could I do? I wanted to serve those Pack 200 ".jar.pack.gz" files from my Apache Web Server.

After some Googling I found this other excellent page by Keith Lea explaining how to set up the whole thing in Apache. It seems you only need to deploy a ".htaccess" file with your application. That simple!!

So I did. In fact I uploaded the whole thing without those fat ".jar" files. I just uploaded the thin ".jar.pack.gz" files. And (as far as I have tested it) it seems the whole think works nicely with Sun's JDK5 Java Web Start clients, both in Linux and in Windows.


But, now, wouldn't it be easier if no server-side stuff has to be set up? Isn't it true that the whole Pack200 technology is badly architected?

It's the java web start clients that should ask for those ".jar.pack.gz" files DIRECTLY!, always, by default.

And if those are not found then the client should ask for the fat ".jar" files, as a second option.

That would make things much easier on the server-side, and will probably help spread the Pack200 technology, which seems to be just excellent.

Now, I wonder if I should file an enhancement request for it on the bugs.sun.com website. Mmmm. I will probably do.

And the example, of course

You may want to try out this syntax-highlighted Scheme Editor built on top of the NetBeans Editor Library, both signed and pack200-ed.

And, yes, I'll be releasing the source code for it soon.

Keep tuned (and have a good unpacked200 weekend ;-) ), Antonio

blog comments powered by Disqus